
Ask HN: How to deal with people that do not follow language style standards? - ghrifter
There are a few coworkers that, _to me_ don&#x27;t follow the proper programming language standards for our platforms.<p>For instance, in any programming language for the past several years, why use a one or two letter&#x2F;char variable name?<p>For example:<p><pre><code>    MusicMP3 m = new MusicMP3();

</code></pre>
vs me (and queue the rather heated discussion)<p><pre><code>     MusicMP3 mmp3 = new MusicMP3();


</code></pre>
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.<p>For the record I&#x27;m a senior for CS.<p>How can I approach the few team members that do _not_ follow programming style guidelines (that are set by our lead Programmer mind you)?
======
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.

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

------
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();

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

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

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

