This edutaining dev rant is another collection of leftover notes and screenshots from various projects, following up to Beyond Googling the Error Message. Here are some funny or rather sad examples of unhelpful automated coding assistance and search results and some strategies to work around that kind of problem.
Unhelpful AI assistance
Grammarly, usually a helpful tool to improve my English skills, sometimes suggests edits that would reverse the intended meaning into its opposite. When writing a paragraph about stack traces, Grammarly suggested that I should change "we can be sure" to "we cannot be sure". Okay?
(Re)search strategies to prevent irrelevant search results
For another blog post, I tried to come up with helpful search strategies like including a framework's version number to prevent irrelevant results from earlier version documentation. Only that Google sometimes ignores parts of the search query, even the words at the beginning.
A search query like "Shopware 6 custom fields don't show" is quite ambiguous, so we need to learn how to include our context and hidden assumptions into a compact question. But search engines might still decide to ignore 90% of our carefully crafted queries.
Inspect if Google removed parts of your search query or if the result mentions theme.json when you want to edit config.xml in a plugin that isn't a theme or if you might have meant WordPress instead of Shopware.
It still helps to include relevant context when searching, but sometimes, software documentation does not make it easy to find the right thing. Shopware, for example, uses two similar subdomains, developer. and developers. for documenting different major releases of their software.
Notice the subtle difference between the Shopware 5 documentation subdomain using the plural form developers.shopware.com vs. the newer Shopware 6 documentation using the singular developer.shopware.com and a blue shortcut icon instead of a black one.
Despite their similar terminology, don't read the "app" docs when you want to code an "extension" (theme or plugin).
I also tried chatGPT. It tends to recommend what I would have done two years ago before recent deprecations, like there is no more psh.phar script, and it prefers using the shop owners' admin UI or an API endpoint even if I ask how to do it "programmatically".
ChatGPT admits that its knowledge is at least two years old and might be outdated.
Undetectable antipatterns?
Static code analysis is an important tool for better code quality. Only that there are some kind of antipatterns that might seem obvious but that can't easily be detected automatically for some reason.
Don't Typos and antipatterns cause warnings?
Another, maybe the most common, reason for any seemingly mysterious error message could be a mismatch of names or namespaces - one of those antipatterns that seem to be so hard to detect that neither IDE and its tools nor any validation nor build step will raise any warning. In hindsight, it is obvious to the human eye that "Tehme" should be "Theme". Anything else would not make much sense. Static code analysis and runtime exceptions often fail to find them, as the code is formally correct, only that something is missing and something unexpected and unused is there instead.
Misleading error messages
The error message details provided by the Symfony profiler can show elaborate details about any irrelevant line invoked in the framework code without mentioning the real reason in our code.
Stack traces are long and verbose but often miss the most crucial information that could be helpful: at what line in which script in my source code did the error occur? Look at this screenshot of a Symfony stack trace of a twig template error.
Only one thing to help us: work in small steps (atomic commits). If our git diff only contains one or a few changed lines, we can be sure where to look for the error.
formally correct?
The following antipatterns are syntactically correct, but they won't work for quite obvious reasons.
Even worse, my editor suggests that the correct line was wrong but the wrong one wasn't.
font-family: var(--wp--preset--font-family--foo); seems wrong only because the context (built-in WordPress default) is unknown to the editor and not explicitly defined in the file, while font-family: "var(--foo-bar)" is very unlikely to work in any imaginable context, unless you manage to name your font family "var(--foo-bar)" if that's even a valid identifier.
I tried to construe a similar antipattern demo using CSS class names that actually start with a dot, e.g.
<div class=".dotted"> which would become double-dotted (..dotted) in CSS.
That's no valid option, but still I haven't seen any IDE or linter suggesting that class=".dotted", getElementsByClassName('.dotted') or classList.remove('.dotted') must be a mistake, not to be confused with querySelector('.dotted') where the leading dot is correct.
get a quote
Mismatching or missing quotes are another common antipattern that is often generated by unhelfpul coding assistance, trying to change a matching quote to the one that you are currently editing, even if it does not match.
Although a missing leading quote will change syntax highlighting colors, most code analyzers will not warn about it.
Pro tipp: if you want to refactor quotings, either use search and replace (and carefully inspect every occurrence) or start by changing the last, not the first quote.
Further reading
I collected more similar examples in a previous post.
Top comments (0)