This has to be satire. Most of these are terrible and I'm pretty sure the fibonacci indentation originated on /g/.
Alternative code styles
71–80 of 107 posts
Re: Alternative code styles
#72Earlier quoted context omitted.
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.
Many programmers are still committed to manual formatting, or fixed width fonts would have been obsolete already.
That said, I haven't seriously tried programming using variable width fonts; maybe it's a well-kept secret to digesting code. Or maybe it's like Hemp Milk, there's a reason it hasn't caught on.
Re: Alternative code styles
#73Earlier quoted context omitted.
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.
Many programmers are still committed to manual formatting, or fixed width fonts would have been obsolete already.
Re: Alternative code styles
#74Earlier quoted context omitted.
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.
There are some limits to what you can automate but stuff like spacing should definitely be enforced by a tool.
What situations have you found where automated formatting doesn’t suffice or has these limits?
Re: Alternative code styles
#75Earlier quoted context omitted.
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.
Many programmers are still committed to manual formatting, or fixed width fonts would have been obsolete already.
And you can still manually format code, serif or monospace.
Proportional or monospace font choice is orthogonal to formatting.
(Edited to be more specific)
Re: Alternative code styles
#76> 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.
Re: Alternative code styles
#77Putting every single item in this on my list of "reasons to kill a motherfucker". Seriously though, I find myself oddly attracted to the Python-braces style .. if only I could use it without running afoul of my own list.
make your syntax highlighter show braces and semicolons in a faint color – similar effect, better editability!
Re: Alternative code styles
#78Earlier quoted context omitted.
There are some limits to what you can automate but stuff like spacing should definitely be enforced by a tool.
I feel like Prettier does a really good job with JavaScript. What situations have you found where automated formatting doesn’t suffice or has these limits?
Some tools order/deduplicate imports. Prettier does not. [1]
And no tool that I've seen orders fields/constructor/method, etc.
Re: Alternative code styles
#79Earlier quoted context omitted.
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…
I think it would help with clarity - too much nesting in a function can mean it's doing too much and might need splitting into several functions
If at each potential error point you best one level, you quickly find yourself deeply nested.
I find the pattern of exiting early and having the “happy path” running to the end of the scope to make it much easier to comprehend a function (I’m sure there’s a term for this coding style but I can’t find the name of it at the moment).
Re: Alternative code styles
#80Earlier quoted context omitted.
I feel like Prettier does a really good job with JavaScript. What situations have you found where automated formatting doesn’t suffice or has these limits?
Ordering code. Some tools order/deduplicate imports. Prettier does not. [1] And no tool that I've seen orders fields/constructor/method, etc. [1] https://github.com/prettier/prettier/issues/949