131–140 of 484 posts
That’s essentially what black has done with Python, though.
I want to like Black (or rather, uv format), but the mandatory trailing commas weird me out, especially in function definitions. It always looks like an error to me.
i wonder how many default formatting decisions are made this way (including go fmt, etc)
I have to disagree with the premise. Formatting code is a critical communication channel. Well-formatted code should tell you: 1. The developer has enough experience to understand that formatting matters. 2. The developer has enough discipline to stick with their chosen formatting rules. 3. The developer has the taste necessary to choose good formatting rules. 4. The developer has the judgement necessary to identify…
Furthermore, instead of nitpicking over small details, it can actually be a good idea to just leave everything on default, forgo whatever your individual style might be and stick to what's been deemed to be good enough as the default - so the code will look more familiar to anyone who picks it up (and has used the tools you use for linting and formatting). Yes, formatting is different from linting; though if you set up one, you might as well do the other.
Earlier quoted context omitted.
Define high? I think 120 is pretty reasonable. Maybe even as high as 140. Log statements however I think have an effectively unbounded length. Nothing I hate more than a stupid linter turning a sprinkling of logs into 7 line monsters. cargo fmt is especially bad about this. It’s so bad.
I still prefer 80. I won’t (publicly) scoff at 100 though. IMO 120 is reasonable for HTML and Java, but that’s about it. Sent from my 49” G9 Ultrawide.
Really suites each language imo Although I could probably get away with 80, habit to use tailwind classes can get messy compared to 120
I have to disagree with the premise. Formatting code is a critical communication channel. Well-formatted code should tell you: 1. The developer has enough experience to understand that formatting matters. 2. The developer has enough discipline to stick with their chosen formatting rules. 3. The developer has the taste necessary to choose good formatting rules. 4. The developer has the judgement necessary to identify…
Earlier quoted context omitted.
Which grep doesn't do and you need to either use a new different tool or more likely several for little real benefit
grep is half a century old now. If we can’t progress our ecosystem because we are reliant on one very specific 50+ year old line parser, then that says more about the inflexibility of the industry to move forward than it does about the “new” ideas being presented.
Grep works great.
I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.
Yes both git and all these PL are actually damn stupid to take lines at face value instead of something more elegant like Ada does. In my 20+ year career I've been proposed only once a project that involved Ada.
It's hard to come with something elegant and efficient. It's even harder to make it reach top tiers global presence, all the more when the ecological niche is already filled with good enough stuff.
Along these lines, Go eliminates many formatting decisions at the syntax level. E.g., func main() { fmt.Println("HELLOWORLD") } is not just non-standard formatting, but illegal Go syntax. Similarly, extra parentheses around if clauses are not allowed.
However 'if (x) == (1) {}' is totally fine with the formatter. As is an assignment of '(x) = (y)'.
It's actively annoying too because like, extra parenthesis often have important meaning.
For example, consider the following code:
if (x.isFoo() || x.isBar()) /* && x.isBaz() */ { /* code */ }
I've hit that far more times than it's uhh... I dunno, I guess removed parenthesis I didn't want? I don't write them if I don't want them.
There’s also a typography element to formatting source code. The notion that all code formatting is mere personal preference isn’t true. Formatting code a certain way can help to communicate meaning and structure. This is lost when the minimal tokens are serialized and re-constituted using an automated tool. https://naildrivin5.com/blog/2013/05/17/source-code-typograp...
(That said, it must be possible to make a more sophisticated formatter for the source code too.)
Earlier quoted context omitted.
Yeah it would probably be a waste of time. It's a nice idea to dream about though. It would be nice to be able to look at some C# code and not have opening curly brackets on a separate line.
I say this fully cognizant of the thread in which it's posted, but these people are sick https://astyle.sourceforge.net/astyle.html#_style=whitesmith And then someone said: oh yeah? Hold my beer https://astyle.sourceforge.net/astyle.html#_style=pico