Undetected antipatterns and missing line numbers
Tags: webdev, programming
Published: 2024-03-05 10:39:41

This edutaining dev rant is another collection of leftover notes and screenshots from various projects, following up to [Beyond Googling the Error Message](https://dev.to/ingosteinke/beyond-googling-the-error-message-lfp). 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?

![Screenshot of an unhelpful Grammarly suggestion](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jvd5rnt0p3ilkskx2xh4.png)

## (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.

![Google results missing the essential query terms](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/inu6wqsbru7crn0sf7r1.png)

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.

![Screenshot collage: Google search, chatGPT and a shrugging ASCII art emoji with questions marks and the numbers five and six](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xu2jhe59g43nyf6ledg8.png)

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.

![Screenshot collage comparing Shopware 6 documentation to its older predecessor](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jynv728ocm9fgh7zc8vk.png)

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".

![Screenshot of a chat GPT output stating that the process might vary depending on the version of Shopware and that its last knowledge update had been in January 2022.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f3doi2yoqfqiket6ryq6.png)

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

![Screenshot of a Symfony logic exception: Controller has no container set, did you forget to define it as a service subscriber?](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zv3s20vap8rz0ez0feft.png)

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.

![Screenshot of a Symfony stacktrace of a twig template error](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5dk0egqxqpl6iaxv42oy.png)

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.

![False positive CSS linting](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4h9kmffqymhw44hf7ft1.png)

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.

{% post https://dev.to/ingosteinke/beyond-googling-the-error-message-lfp %}