Code Pet Peeves: What's Yours?

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!

The DEV Team Follow

The team behind this very platform. 😄

Comments

[Thomas Pegler]

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)

[insidewhy]

I have a slight preference to leave semicolons out whenever possible. Minimalist. It doesn't really bother me either way.

[Nabil Alamin]

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.

[Nwanguma Victor]

For me its the opposite, putting new lines only when necessary helps to know if pieces of code are related.

[Nabil Alamin]

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.

[Nwanguma Victor]

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.

[Nabil Alamin]

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

[James Owens]

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.

[Nabil Alamin]

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

[Khairunnisaas]

i agree for that

[Jon Randy 🎖️]

Spaces being used for indentation instead of tabs.

[Michael R. Taylor]

Yes, this one! And to go along with it, at least for me: using tabs for alignment. 😠

[Retiago Drago]

Cannot be consistent with either this

def add(a, b, c):
    return a + b + c

add(a_very_long_variable_a,
    a_very_long_variable_b,
    a_very_long_variable_c)

or this

def add(a, b, c):
    return a + b + c

add(
    a_very_long_variable_a,
    a_very_long_variable_b,
    a_very_long_variable_c
)

[Khairunnisaas]

bottom one is much better for me

[AlteredOxide]

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.

[Retiago Drago]

sometimes the former saves more space 😭

[Ben Halpern]

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 (computer programming)

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.

View on Wikipedia

[XANOZOID]

No comments

[Mike Stemle]

My pet peeve is folks having too strong of an opinion about syntax.

• Spaces or tabs? I’m bored.
• Semicolons or not? Yawn.

I’m also rather annoyed by the over-emphasis on OOP as though it is the only correct paradigm.

Finally, I don’t like folks who behave like one language is better than another. They’re tools, not political positions.

[Mike Lowe]

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 😭

[Nicolus]

Oooh, you would love working with me : I tend to rearrange variable declaration blocks to order them by line length so it looks nice.

[Keith Solomon]

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…

[Nicolus]

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 😉

[Keith Solomon]

She wasn’t give a spec for it, and I didn’t say anything about it…I suffered in silence… 😂

[Jake Lundberg]

I have 3 that really get to me:

1. inconsistent code formatting. i’m fine adopting different patterns or standards, but that pattern should be consistent throughout the codebase.

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

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