Welcome to Code Chatter, your go-to series for conversational coding insights. What makes this series of questions different from all the others? Well, truth be told, not much, but they're still thought-provoking and fun. Join us as we explore the coding world, one witty question at a time.
What's your secret 'code pet peeve' that, while not critical, drives you crazy?
Follow the DEVteam for more discussions and online camaraderie!
Top comments (36)
This is so silly but I really don't like the Javascript pattern of not using semi-colons and trying to remove as much punctuation/structure as possible. I get the desire for conciseness but not having reliable beginning and end-points in code bothers me. I'm saying that as a Python developer (sometimes I wish Python had more punctuation but at least whitespace is the delimiter)
I have a slight preference to leave semicolons out whenever possible. Minimalist. It doesn't really bother me either way.
My biggest would have to be spacing of code blocks, seeing large lines of code all together with no breathing room is just awful and slows down the readability.
For me its the opposite, putting new lines only when necessary helps to know if pieces of code are related.
Yh, I agree, but, there are cases where a new line really makes it easier to read, even when they are related. Take this for instance:
I'd say the latter makes the block a bit clearer.
Cleaner does not necessary mean readable. i.e there are one-liners that are cleaner but not readable.
In your example, It would be annoying If I was scrolling through the code and, at every new-line stop to try and contemplate if the code above and below is related or not.
Yh, one liners can be tedious.
The example I gave is about readability, the nesting also helps you to understand that's it's part of the same context, collapsing that block could also help you along.
At the end of the day I think it's just up to what your team agree is the pattern to follow
If you're separating blocks of code that are related with new lines it could be an indication that your blocks could be extracting into separate methods.
Definitely agree, this example is not the end and be all. In that case I was going by the rule of only abstracting when there is a repetition of more than 3. It's all opinionated though
i agree for that
Cannot be consistent with either this
or this
bottom one is much better for me
Yes. The first one irks me, especially because that first argument is rarely perfectly aligned with your chosen indentation (2, 3 or 4 spaces), which leads to needlessly tedious manual spaces or deletions before following argumentsādepending, ofc, on your linter.
sometimes the former saves more space š
Spaces being used for indentation instead of tabs.
Yes, this one! And to go along with it, at least for me: using tabs for alignment. š
I don't know if it's a pet peeve, but premature abstraction/DSL-ification grinds my gears, i.e. violating the "rule of three"
Rule of three is a code refactoring rule of thumb to decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code do not require refactoring, but when similar code is used three times, it should be extracted into a new procedure. The rule was popularised by Martin Fowler in Refactoring and attributed to Don Roberts.
No comments
Not strictly code but I tend to alphabetise things like environment variables in config files, YAML, JSON param files for CloudFormation, that sort of thing. It pains my heart when someone comes along and just throws new variables/params in in any old order š
Oooh, you would love working with me : I tend to rearrange variable declaration blocks to order them by line length so it looks nice.
Itās code-ish, but I ran into this doing a review with one of our juniors today. She was working on the mobile side of a site, and had the hamburger menu on the leftā¦thatās not a problem. The problem is, the menu opened from the right. Itās so minor as to be pointless, but it drives me crazy to see thatā¦
Well to be fair if the spec she was given didn't specify what the hamburger button was supposed to do, she could have made it randomly open at the top/bottom/left/right and it would have been just as correct š
She wasnāt give a spec for it, and I didnāt say anything about itā¦I suffered in silenceā¦ š
I have 3 that really get to me:
inconsistent code formatting. iām fine adopting different patterns or standards, but that pattern should be consistent throughout the codebase.
when someone says āweāll circle back and fix this laterāā¦in my experienceā¦no we wonāt. unless this is a prototype and the team understands that this code will be thrown away, letās do it correctly now.
duplicate code. it may be easier for you in the moment to copy a chunk of code to get something working, but it causes so much more pain later. invest a little time now rather having to pay interest on that time later.