31–40 of 107 posts
Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.) I'm happy.
I don't think even you believes that. You're telling me you would be "happy" if every source file was one line?
Earlier quoted context omitted.
I'd prefer something like 3^n. Would really make you try to avoid needless nesting.
Why should I avoid needless nesting ? Is there any other reason besides the holy 80 character limit !? Nesting can for example be used to limit variable scope and make use of closures, or to avoid creating more code paths, or just make the code more readable. You can however often break some code down to named functions and it will be easier to read, with the added benefit of less nesting. But I don't see how avoidin…
Because it is, by definition, needless. If there is a good reason for doing so, it is no longer needless.
Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.) I'm happy.
I don't think even you believes that. You're telling me you would be "happy" if every source file was one line?
The only style there that is actually used by a person is the Bourne style. There are other styles that people develop for themselves, for example there was some Haskell program posted to a mailing list with a warning about personal style. This defines: (.) :: a -> (a -> b) -> b x.f = f x And then the author can write e.g. x.length Instead of length x I think this is really quite a natural operator (and other languag…
Earlier quoted context omitted.
I'd prefer something like 3^n. Would really make you try to avoid needless nesting.
Why should I avoid needless nesting ? Is there any other reason besides the holy 80 character limit !? Nesting can for example be used to limit variable scope and make use of closures, or to avoid creating more code paths, or just make the code more readable. You can however often break some code down to named functions and it will be easier to read, with the added benefit of less nesting. But I don't see how avoidin…
> Poetry... quite eye-pleasing I disagree with this comment. That style makes the code extremely hard to follow, as there's no proper indention to identify scope.
Earlier quoted context omitted.
:O that is ... interesting. Sure that's not an entry for the ioccc? ;)
Nope :) This is being used everyday in production by most financial institutions. https://code.kx.com/wiki/Cookbook/InterfacingWithC I've been told that the guy who wrote this believe that the brain only has a limited buffer to compute source code. So he is trying to use the shortest code possible everywhere.
Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.) I'm happy.
At the end of the day, it is important that the code looks like it was written by one consistent person and not 20 random different people.
Earlier quoted context omitted.
I don't think even you believes that. You're telling me you would be "happy" if every source file was one line?
Lint to personally preferred style on checkout. Lint to project style on checkin. Not a problem.
Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.) I'm happy.
Put another way... if the proponent of a particular (serious) syntax style guide can't be bothered to automate it, then they are pissing in the wind. I laugh when I see those 50-page English-language documents describing how some institution wants code to be formatted. Ain't nobody got time for that.