
Ask HN: Does code style matter to you? - rtfpessoa
When working in company, where more than a couple of people share the same code base, should we enforce a code style?<p>Is it fair to ask someone to fix a style&#x2F;comprehensibility issue like: change a variable name; prohibit lines longer than N chars, ...<p>or should you just focus on the feature&#x2F;behavior the code should implement&#x2F;fix?<p>What are you doing in your current job:<p>- Do you have a well defined code style? Is it public? Where is it?<p>- How do you enforce it? Comment on commits&#x2F; pull requests?<p>- Are you automating style reviews? How? Are you using tools like JSCS, Scalastyle etc? Are you using services like Codacy?<p>- How do you think a well defined code style is helping your code&#x2F;work?
======
noir_lord
Change a variable name, yes absolutely depending on context and the language
in use, this can range from using foo_bar/fooBar through to inappropriate
variable names (I've seen swearwords used as variables when someone has been
doing debugging in code and needed to grab intermediate values, seeing "cunt
is undefined" in the console is not going to do you any favours on the
professional scale) or ones that lack clarity.

Prohibit lines longer than N chars, again absolutely, many languages have
standards like Pythons PEP8, I find 80 chars constricting sometimes but I
stick to the standard because it is the standard (de-facto or not).

\--

I stick to standards where they exist, for PHP thats the relevant PSR's, for
Python, PEP8.

I enforce it by using the IDE to flag non-conformance and auto format either
on the fly or on save, since I'm the only dev I don't need to enforce it on
commits/pull requests.

Style Reviews are not applicable since there is just me (see above).

I think coding against the languages 'default' styles whether de-facto or
imposed (I wish all languages had gone the gofmt route so we could obviate
this problem nearly completely) helps, it certainly requires less context
shifting when jumping from code I wrote to third party libraries in the same
language.

In the past when I've worked with teams I've found having a defined standard
helps hugely since it settles the inevitable bikeshedding arguments that crop
up when programmer A wants to do foo and B do bar, often there is no clear
winner so just picking one and adding it to the standard kills the argument
dead the next time.

Personally I've always preferred :-

    
    
        if foo()
        {
            stuff();
        }
    

to

    
    
        if foo(){
            stuff();
        }
    

but since PSR2 says not to do that I stopped (or more correctly I let the IDE
handle it till it became habit to do it PSR style).

------
bikamonki
I'd say yes but don't get too strict about it. It is common sense and the key
point is readability. Long lines are hard to read, avoid them. Meaningless
variable names are hard to follow/read, avoid them. Un-indented code is hard
to read, avoid it. Shorthand statements are hard to read, use them but train
your programmers to use them. Break long/big functions into smaller ones.
Agree on files/directory structures. In my company we've never used hard
rules, mostly common sense, and I think it's working.

As long as readability is working for everyone, rules that are too picky like
camel case vs underscore, indent with tabs vs spaces, etc, will just add
overhead.

------
dudul
I like to enforce code style because I use automated-formatting on all the
files I change. So, to avoid useless lines in git diff we have everybody use
the same settings in their IDE to make sure we don't have to go through a
bunch of "tab to space" changes.

I personally don't care much for style per se (e.g. should I leave an empty
line after each class declaration and garbage like that). The only one I like:
no lines longer than 80 characters, simply because I occasionally work on
small laptops and like being able to see the whole line at once.

------
hex13
Code style doesn't matter but tools like Eslint (or other linters) that can
enforce some unimportant stuff, can also be very huuuuuge help for JavaScript
programming. They can point most JS errors, for example.

~~~
hex13
I mean code style doesn't matter in JavaScript world. If I was developed in
Python I would follow PEP8. But this just proves the point - code style
doesn't matter to me much, so I could follow some other's codestyle, just to
keep standards.

