Tabs for indent, spaces for alignment. This is the way, I can't believe people are still fighting that ?
Anything for indent (barely matters, as long as the editor forces it to stay consistent), and fuck alignment, just put things on a new line.
struct Ident arr = [ { .id = 0, .name = "Bob", .pubkey = "", .privkey = "" }, { .id = 1, .name = "Alice", .pubkey = "", .privkey = "" } ];Not like that, lol
Just saying, instead of this monstrosity
CreateOrderRequest(user, productDetails, pricingCalculator, order => order.internalNumber)Just use
CreateOrderRequest( user, ...Putting the first argument on a separate line.
Same if you have an
ifusing a bunch ofand(one condition per line, first one on a new line instead of same line as theif) and similar situations.When I talk about alignment it's not about function arguments, but values, "=" signs and such. You simply cannot use tabs for that because alignment must be fixed and indentation independent:
CreateOrderRequest( user, productDetails => order.detail, pricingCalculator => DEFAULT_CALCULATOR, order => order.internalNumber)
Another accessibility reason for tabs: when using a braille display, each space takes up one character cell, so indenting with four spaces eats up four cells. Indenting three times with four spaces each eats up 12 characters already. Tabs only take one character cell each, so three indents = three character cells used.
The fact that there (I assume?) isn't a braille oriented text editor that can handle space-based indentation in a smarter way is a bit depressing. Maybe the solution should be better tools based around accessibility rather than convincing everyone to switch to tabs, which is a project that will just never succeed.
rather than convincing everyone to switch to tabs, which is a project that will just never succeed.
Few years back, Coraline Ada Ehmke went on a one person crusade opening a pull request on every major Github repository to adopt a code of conduct for the project, detailing the complex rules of how the humans in that microcosm of a project should interact with one another. Today, it's the norm.
Arguing that it's invincible to convince people at large to adopt tabs over spaces with good arguments is a ridiculous statement. All you are doing is making up excuses for not having to care.
Tabs let you define how big you want each indent to be
…except when they don't. Many common environments have a hardcoded tab size of 8, which is insanely big for using it for indentation.
What environment are you using that has a hardcoded tab size? I haven't seen this since typewriters.
Some projects just use tabs as a compressed form of 8 spaces. But that is a sin. Use tab to mean "one indent level" and align with spaces if you need to. (the occasional ASCII art diagram)
What environment are you using that has a hardcoded tab size?
- Termux
- SourceHut
- “View page source” in the browser
Termux
I think running
tabs -N(whereNis you preferred tab size) in the terminal should work. This is what I use in my zshrc on desktop.SourceHut
Yup, they seem to be pretty opinionated here. If you look at the source there is just an inlined style with a single rule
pre { tab-size: 8 }. I guess that is what you get when you use opinionated tools. The user's browser isn't right, my preference is right!“View page source” in the browser
On Firefox this uses my default tab size of 4. But I guess changing this default isn't user-friendly.
Because other people might have restricted environment which might not suit their preference is not a good reason to level it down IMO.
Also, I think 9 is the best size for indent (matter of preference), do you think I should switch to space so everyone can enjoy this wonderful view I have ?
As an embedded software developer that does linux kernel drivers I've come to love the tab size 8 indentation level.
I'm paraphrasing: "if your indentation level gets too deep, it's time to rethink/refactor your function."
And with tab 8 you'll notice it rather quick if your function does too much/unrelated stuff.
A function should be short and do one thing only, if possible. It also makes unit testing easier if that's a requirement.
When you're operating on such a low level of abstraction, it's no wonder you don't need deep nesting.
Oh, I've done my fair share of C++ and Python as well. But you got to agree with me that when you are on your fourth indented "if case" it's time to step back and think about what you are trying to achieve. I mean it's probably going to work, but probably also very hard to maintain that type of code.
How would you implement, for example, Gaussian elimination with at most 3 levels of nesting?
There a many ways to implement abstractions, but it’s highly dependent on the language in question. You could simply refactor each level of nesting into its own function, with all dependents provided as parameters instead of scoped variables. You could then flatMap to avoid a bunch of nested looping, favoring a linear approach that’s often easier to reason about. You could go all out and refactor all your conditional statements away, in favor of the Either monad. You’d then have a number of functions, each doing one thing (including no nesting), and a main function gluing it all together, linearly. That is a pattern you can always apply; there’s nothing controversial about it, and on a similar note there’s nothing particularly challenging about Gaussian elimination.
Neither tabs or spaces are good. The correct way is to leave no whitespace in the code at all. It's unnecessary and adds to processing time.
Everyone should aim for 1LOC per commit
