Ask HN: Does code style matter to you? | Hacker News Reader

Ask HN: Does code style matter to you?

3 pointsrtfpessoa5 comments

When working in company, where more than a couple of people share the same code base, should we enforce a code style?

Is it fair to ask someone to fix a style/comprehensibility issue like: change a variable name; prohibit lines longer than N chars, ...

or should you just focus on the feature/behavior the code should implement/fix?

What are you doing in your current job:

- Do you have a well defined code style? Is it public? Where is it?

- How do you enforce it? Comment on commits/ pull requests?

- Are you automating style reviews? How? Are you using tools like JSCS, Scalastyle etc? Are you using services like Codacy?

- How do you think a well defined code style is helping your code/work?

View on HN

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

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

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.

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.

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.

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.

Reply on news.ycombinator.com