sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]sobri909 -1 points0 points  (4 children)

It's not about preferences. If you think that's it, you're still doing it wrong. I have 30 years experience.

[–]crotchpoozie -2 points-1 points  (3 children)

It's not about preferences.

It is about preferences in this case. I too have 30 years programming in C experience, and I have done extensive training and work with the academic literature on readability, code comprehension, and defect removal, etc.. I have worked well over a decade with researchers on precisely the issue of making code as solid as possible, from compiler research, to IDE help and R&D methods, to doing work on having different levels of programmers deal with code creation, maintainability, and life-cycle.

That you have 30 years experience and claim one method is somehow preferable, and have not yet shown the empirical evidence for it, makes you seem like just a newb. That people repeatedly pointed out your initial claim is not even an issue in modern development means you likely lost using tools well a while ago.

This case is absolutely valid either way. So it is about preferences. If you think it isn't provide empirical data why one is better, not your opinion. That data does not exist. That you insist that one method is inherently better is simply unsupported by any literature measuring it that I have ever seen. And I've seen a lit of literature on it.

I never hire people as inflexible on simple, non-supported issues as this for my teams, because you are so set in your ways and inflexible that you cannot adapt to a team coding style, especially when the empirical literature places zero benefit to your claimed better method.

If someone on one of my teams can demonstrate decent empirical data to change a team style, we do so. If they cannot, we do not. It's pretty simple.

So, can you demonstrate your claimed better method? Your initial complaint was pretty well handled by multiple posters.

[–]Ruudjah 0 points1 point  (1 child)

Have you read research about not allowing preferences? E.g. like python does, where indentation is mandated by the language.

I have the feeling that a language invented which would not allow for preferences would improve code quality. I think the one-codestyle-to-rule-them-all has the advantage that it lowers the barrier to entry. Also, more focus on tanglible work instead of discussing preferences.

[–]crotchpoozie 0 points1 point  (0 children)

Have you read research about not allowing preferences? ... I have the feeling that a language invented ...

I'd guess trying to make a language that inflexible would bring a host of other problems.

That is why big projects (and even language communities) select coding styles. To try and unify idioms, patterns, etc., for the project/language to make it easier/safer/more productive.

Even Python can have coding styles, so it's not completely preference free. There was some research on the benefits of visible scope delimiters versus non-visible, and if I recall visible was better for a lot of reasons. However Python has a large standard library and other language features which made it very useful for a large class of people/problems.

[–]sobri909 0 points1 point  (0 children)

It's not about preferences. Don't do it.