HN Explorer

Ask HN: How to deal with people that do not follow language style standards?

2 points by ghrifter ↗ HN
There are a few coworkers that, _to me_ don't follow the proper programming language standards for our platforms.

For instance, in any programming language for the past several years, why use a one or two letter/char variable name?

For example:

    MusicMP3 m = new MusicMP3();
vs me (and queue the rather heated discussion)

     MusicMP3 mmp3 = new MusicMP3();
What gives? This guy is fresh out of college and should know not to name variables like this.... no longer is the day 8char restricted variable names.

For the record I'm a senior for CS.

How can I approach the few team members that do _not_ follow programming style guidelines (that are set by our lead Programmer mind you)?

7 comments

[ 4.9 ms ] story [ 44.6 ms ] thread
coreyp_1
Whose job is it to enforce the coding standards? Let that person take it up with them. That is their job, after all.

Personally, though, I would also be gently saying things like, "Dude (or Dudette), you know that's not going to pass code review, right?" Maybe I should clarify: you DO have code review, right?

Without trying to be too elitist, I would say that a programmer who codes sloppily or cryptically does not have a good philosophy of coding, and that is dangerous in the long run. That is, they don't understand the purpose of programming languages and how they should be used. Higher order languages are an abstraction that is for the benefit of the programmer, not the computer. If you don't use the language correctly, then you look like a Neanderthal. It's like going to a Chinese restaurant and pulling out a bottle of ketchup. You clearly don't get it.

If a programmer refuses to write easy-to-read, contextual code, then they will not stay employed by me for long. To me, they are not just being "clever" or "economical", but rather are demonstrating an unrefined bruteness in a profession that requires sophistication and grace. Programming is art, and they are trying to paint with a shovel.

jasonkester
He's right. For a local variable that's only going to survive a half dozen lines? I'd use your buddy's name over yours.

For a class member or anything with a long life, I'd use something longer and more descriptive than yours. We already know it's an MP3 from the type. The name can tell us what it's used for:

  MusicMP3 nextTrack = new MusicMP3();
insoluble
Perhaps they have never had to decipher lengthy cryptic code written by others, nor code written by themselves in the distant past. Maybe you could throw some ugly, cryptic code at them and let them experience firsthand what it's like dealing with vague, ambiguous code.
bjourne
> This guy is fresh out of college and should know not to name variables like this....

> For the record I'm a senior for CS.

That's a poor form of argumentation.

In your example, assuming the MusicMP3 variable is local, and the function is reasonably short, then it is preferable to use a short name such as "m" over a longer but equally uninformative name such as "mmp3". In programming just like in mathematics, we are often more interested in how values interact with each other than with what they are. Short names makes the interactions easier to see, e.g:

    diag_len = sqrt(w * w + h * h)
Is much better than:

    rectangle_diagonal_length = square_root_of(rectangle_width * rectangle_width + rectangle_height * rectangle_height)
Maybe I have still not convinced you and that is ok. But now you see it is a matter of taste. So why get upset over if someone names a variable "m" instead of "mmp3"? Is it the end of the world?
ghrifter
Thanks. I should have put in OP that some of these method bodies are dozens of lines (sometimes approaching 100+).

Some of these variables are used quite often.

saywahat
Depends on the scope. "apple[i]" is more readable than "apple[apple_index]".

Long names are for globals or longer lived scopes.

Java programmers are notorious for using long names in small local scopes. Don't miss the forest for the trees.

inlineint
I think that the best way to deal with it is to discuss the problem with your team lead and introduce a mandatory code review process in your team.

I mean using of Crucible, Github pull requests or something like it and reviewing all commits by one of senior developers. Then commits that don't follow coding standards of you team will be rejected in the issues will be fixed. However you also have to establish coding guidelines for your team to use them as a reason to reject some commits.

It will not only help your team with following coding style guidelines, but also improve the code quality in general.