Hacker News Reader

Comment by VeejayRampay | Hacker News Reader

I've always thought that what makes code hard to read is the fact that several persons are usually working on it. Beauty is in the eye of the beholder as we all know. Some developers like snake case, others prefer camel case. Some prefer 4-space indentation, while other can't stand it and much prefer 2 spaces. Some like braces on the same line, some others prefer it on the next line.

What really bothers me is that editors in general force people to share a codebase formatted for a given style that may or may not satisfy everyone.

And the worst is that I don't see why that has to be. Ideally "code" would be some form of abstract syntax tree and the editor would apply a user-generated "stylesheet" on top of it to display the code as the user wants to see it.

Upon save, all the style would go away and only the abstract representation of the code would go to the shared repo.

Not an easy thing to make happen for sure, but that'd be awesome.

View on HN

If you work in a team you absolutely MUST enforce a coding standard. It better be a community standard most of developers use. All team members must use either tabs or spaces and have IDE configured to automatically apply styles.

It will save A LOT of time later.

I (respectfully) disagree. The editor should take care of adapting the codebase to the standards the programmer likes. Trying to force 20 developers into a "consistant" style only makes room for a soft consensus that doesn't satisfy anyone in the end.

If we can do it for web pages (with CSS) there's no reason why we couldn't be able to do it for a source file.

In any IDE you can set up code formatting options. By pressing a button you are essentially applying this CSS you are talking about. You can write however you want but when saving a file you (either manually or automatically) should execute reformatting in IDE.

I agree with you that having CSS-like option would be better, since code is data, CSS is formatting options. But you'd have to teach all other tools you use to work with this CSS approach. For example for git source files are just text. Git doesn't understand code semantics. For its diff routine tabs changed to spaces == every line of code changed.

There's no much use for a VCS if every commit changed everything.

The problem is that coding style goes deeper, it goes right down to the abstraction.

You're absolutely right. It's about design more than anything else, but at least for the cosmetic details, I feel the current state of affairs is sub-optimal.

Cosmetic? Visual Studio fixes layout problems in a few keystrokes but it can't fix, say, poorly named variables.

By cosmetic, I mean the pettier details like indentation, method names in bold or underlined, return types on the same line or before the function definition, position of braces, snake case versus camel case, etc.

That I think the editor should take care of. For more serious issues like your example of poorly named variables, there's nothing it could do (and is really the core of the problem, as you pointed out).

This is why it's important that you have a coding standard but not so important what choices it actually makes. Just like you have to pick whether to drive on the right or the left.

Golang apparently enforces a visual style. To a certain extent, Python does as well.

Python really should try harder to enforce visual style. The tab-space munging that you can get away with is horrible.

Reply on news.ycombinator.com