181–190 of 238 posts
If your style rule is 4 spaces, you have 3 invalid indentation levels for every valid one. Even if you only use two spaces half your possible indentation levels are invalid.
The number of times in my life I've been editing a space-indented file in vim on some sshed server and had to count spaces is way too high.
It's slightly insane that computer programs are still mostly derived from plaintext files.. but what's absolutely insane is that we, the people creating those programs, do so by modifying individual characters in those very same plaintext files.. Yes, text is a good interface medium for exchanging program descriptions between humans and machines.. but it's not a very good medium for storing and exchanging program des…
> variable naming and so on.. all stuff that's there for the humans, the compiler don't care what you name your variables.. It's insane that there's no abstraction here.. You would have variable names not saved? They don't matter for the future maintenance of the program? You can have most of what you ask right now, the further step most relevant here would be to not indent anything in the saved code; with most langu…
For example, a variable holding a.. users actions per second. Say I've set up my editor for camelcase, I'd type in userActionsPerSecond, the editor would save the metadata as user,actions,per,second. Another programmer prefers underlines, their editor presents it user_actions_per_second, and a third user prefers it space seperated, but with a box drawn around it to indicate it's one thing and it's presented [user actions per second] or whatever. I'd maybe add a comment as metadata to the variable too, the comment could easily be shown above the variable, just as it is today, but they can never get detached by someone adding another item between the comment and the variable. Some people would prefer no comments at all, others want them always visible, others want them visible on mouse over.. lots of options.
I know I _can_ have almost all I'm asking for, but the hoops we jump through to get them due to storing program descriptions (source code) as plain text directly, with no really good way to add additional information to it (see the many horrors we have with annotations in different languages, for instance javadoc where comments are abused to embed a different kind of language carrying metadata which is only incidentally coupled to what it tries to decorate).
Instead of doing tricks to separate content and presentation, it should be the default approach.
Our entire infrastructure, grown organically over the past what, 40+ years, arrange itself around individual bytes arranged in text files, arranged in folders.. And I get that thinking this must be the best and final form is easy, because, honestly, software development tooling and infrastructure is some of the best and most solid software ever written, no doubt because it's written by the people using it.
It's not like I've talked with god and come with a list of solutions to problems nobody is having, only that, while I'm not really dissatisfied, I've stumbled into this way of thinking about building programs, it's partly due to some brain damage I must have gotten from learning and thinking about lisp, and while lisp does lots of things wrong, it gave my brain this twist that the models we hold of how to do things can be very different from what we're used to.
I think it's worth at least once in a while, to put some ideas on the backburner and entertain ourselves by imagining other approaches other approaches than arranging individual characters in files, which is the lowest form of computer interaction you can imagine outside of writing bits and bytes directly into memory cells. And it's a bit ironic that as we do this very high-level, high abstraction work that is composing a program, using the most primitive interaction with the machine that's still available through user-programs: manipulation of the arrangement of bytes in files.
If you look at modern development, there's still a fairly noticeable part of it that's centered about ascii-art, either directly by hand, or by instructing the editor to do it, and there's a lot of procedure that's there not to describe programs, but to help derive the programs out of the source texts.
Meanwhile, the war on tab width marches on. Back when I got tired of inconsistent tab widths, I simply based my preference on the silly fact that some research showed how developers using two spaced tabs make slightly more money. Among our team we do not enforce a specific width, but respecting the choice of the original author of a project is required. Kind of annoying how LLMs will sometimes randomly decide to chan…
If you enforce a specific width it's dumb to use tabs, just use spaces
Tabs are better, simply because you can view them as you like. Go obviously does this, and Haxe too (with default formatting options, even tho its configurable)
This works until someone tries to vertically align something like a table or a line that is wrapped.
Earlier quoted context omitted.
Not if you learn to use the right shortcuts for it (ctrl+arrows, mostly).
I know the shortcuts. (It’s not ctrl-arrows; ctrl-arrows is to switch Space.) There are still situations where it’s annoying, mostly when navigating the code using the arrow, moving from one location to another using the arrows, I won’t add a key modifier right in the middle of moving the cursor, it just doesn't make sense.
Earlier quoted context omitted.
This works until someone tries to vertically align something like a table or a line that is wrapped.
That’s mostly editor braindamage (that has unfortunately leaked into some otherwise very good codebases, like LuaJIT). Indent things with tabs, align with spaces[1]: if (foo) { » frobnicate(bar, » ...........baz); } Both camps will hate you, but things will work just as they should. [1] https://www.emacswiki.org/emacs/SmartTabs
Tabs are better, simply because you can view them as you like. Go obviously does this, and Haxe too (with default formatting options, even tho its configurable)
Spaces are better, simply because you don't have to worry if another developer is seeing the code different than you. See, I can do it too. This is why there is an ongoing discussion. Because there is no clear cut answer, just opinions. At least this article brings some data to the discussion.
Earlier quoted context omitted.
> another developer is seeing the code different than you. but that's the whole damn point ... I like substantively indented code, you prefer minimally indented, we should both be happy (and we can be, by using tabs).
You could certainly make that argument. You could also make the argument that all the developers on a project seeing the same view of the code enhances collaboration and team cohesion, especially if your team does pair programming. This is often why dev teams have more specific style guides that include things would be considered bike-shedding, like how many spaces an indent is.
Earlier quoted context omitted.
No one who uses tabs would ever assume a certain tab width for visual alignment. What do you base that slanderous statement on? I've also never heard anyone argue that someone else should configure some different tab width, is there a specific language ecosystem you were in that had these insane takes?
To quote the linux kernel style guide: > Tabs are 8 characters, and thus indentations are also 8 characters. Yes, tabs are used for alignment as well. To quote the OpenBSD style guide: > Indentation is an 8 character tab. The GTK source code uses tabs when the number of spaces for indentation >=8. This goes against their coding-style document, but if you don't have tabs set to 8 you'll find the indentation broken. gi…
It's slightly insane that computer programs are still mostly derived from plaintext files.. but what's absolutely insane is that we, the people creating those programs, do so by modifying individual characters in those very same plaintext files.. Yes, text is a good interface medium for exchanging program descriptions between humans and machines.. but it's not a very good medium for storing and exchanging program des…