I set my clang-format to tabs only (actual tabs ASCII 0x9, no alignment and there is a continuation tab instead), then anyone can set their editor to whatever tab length they feel like and look at their code however they want.
But no spaces on the left of my code. This is for C, C++ and JSON.
Linux uses 8 spaces. Excerpt from the official style guide:
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you’ve been looking at your screen for 20 straight hours, you’ll find it a lot easier to see how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program.
In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning.
NASA also built the space shuttle, which was a plane that couldn’t fly by itself (as it was supposed to), was slower to turn around and more expensive than older equivalent technologies, and blew up all the astronauts 1.5% of the time.
I mean, they’re great at other things - who else could have made the JWST work flawlessly with one opportunity - but they’re a definite source of hype, and they do something very particular and specialised. Beware endorsements.
Edit: Fuck you, I’m right. Keep 'em coming.
I don’t even care about Agile either way. This just isn’t a good argument for it.
Yep. They’re probably better than anyone at making a complex system with literal moving parts that works 100% of the time, the first time. On a nearly unlimited budget, with a decades-long schedule. In an institution and culture that’s now a been around a lifetime, staffed with top-notch people.
That’s all perfect for what NASA does, but I wouldn’t recommend a management system that NASA uses to just anyone, just 'cause “da astronauts” use it. Not any more than I’d recommend drinking your own distilled piss to anyone.
I don’t really have an opinion on Agile, even, I just have a problem with selling it this way.
I can see you’re frustrated by the downvotes and pushback you’ve received. It’s understandable to feel defensive when your viewpoint isn’t well-received. I appreciate you sharing your perspective, even if it goes against the majority opinion here.
Your points about the space shuttle program’s challenges are valid and worth discussing. It’s important to note the timeframes involved though. The shuttle was developed in the 1970s, well before agile methodologies emerged in the 1990s and 2000s.
Interestingly, one could argue that NASA may have used agile-like practices in the space shuttle program, even if they weren’t labeled as such at the time. However, I did a quick search and couldn’t find much concrete evidence to support this idea. It’s an intriguing area that might merit further research.
Regarding modern agile approaches, while no method is perfect, many organizations have found them helpful for improving flexibility and delivering value incrementally. NASA’s recent use of agile for certain projects shows they’re open to evolving their methods.
I’m curious to hear more about your thoughts on software development approaches for complex engineering projects. What do you see as the pros and cons of different methodologies? Your insights could add a lot to this discussion.
I can see you’re frustrated by the downvotes and pushback you’ve received. It’s understandable to feel defensive when your viewpoint isn’t well-received. I appreciate you sharing your perspective, even if it goes against the majority opinion here.
Thanks for the kind words. FWIW I’m doing fine, this feels like a worthy fight. I know a bad appeal to authority when I see one.
Interestingly, one could argue that NASA may have used agile-like practices in the space shuttle program, even if they weren’t labeled as such at the time. However, I did a quick search and couldn’t find much concrete evidence to support this idea. It’s an intriguing area that might merit further research.
I appreciate your candor about not wanting to speak on topics outside your expertise. That’s commendable. I wonder if we can still talk with the understanding that we may not know it all. I truly believe curiosity is able to sidestep many of the problems related with ignorance.
You’re right to be cautious about appeals to authority. My intention wasn’t to suggest NASA’s use of Agile validates it universally, but rather to counter the OP comic’s implication that Agile is inherently incapable of achieving significant goals like space exploration.
Regarding Agile-like practices in earlier NASA projects, you’re correct that concrete evidence is limited. However, we can analyze their approaches through the lens of Agile principles. Scrum, for instance, aims to foster characteristics found in high-performing teams: clear goals, information saturation, rapid feedback loops, adaptability to changing requirements, and effective collaboration. These elements aren’t exclusive to Scrum or even to modern Agile methodologies. The key is recognizing that effective project management often naturally gravitates towards these principles, whether formally adopting Agile or not.
It’s an interesting area for further research: have complex engineering projects historically incorporated elements we now associate with Agile? If so, how?
Your skepticism is valuable in pushing for a more nuanced understanding of project management across different domains.
It’s kind of insane how bad this whole is-number thing is. It’s designed to tell you if a string is numeric, but I would argue if you’re ever using that you have a fundamental design problem. I hate dynamic typing as much as anyone else, but if forced to use it I would at least try to have some resemblance of sanity by just normalizing it to an actual number first.
Because of the insanity of keeping them strings and only attempting to validate them (poorly) up front you open yourself up to a suite of bugs. For example, it took me all of 5 minutes to find this bug:
<span style="color:#323232;">toRegexRange(</span><span style="color:#183691;">'+1'</span><span style="color:#323232;">, </span><span style="color:#183691;">'+2'</span><span style="color:#323232;">)
</span><span style="font-style:italic;color:#969896;">// returns "(?:+1|+2)" which is not valid regexp
</span>
The problem is the underlying API. parseInt(“550e8400-e29b-41d4-a716-446655440000”, 10) (this is a UUID) returns 550. If you’re expecting that input to not parse as a number, then JavaScript fails you. To some degree there is a need for things to provide common standards. If your team all understands how parseInt works and agrees that those strings should be numbers and continues to design for that, you’re golden.
Yeah good point. I suppose the problem is this function that operates on numbers allows numeric strings to be passed in in the first place. The only place where I would really expect numeric strings to exist is captured directly from user input which is where the parsing into a numeric data type should happen, not randomly in a library function.
Ruby syntax is nice although I prefer python way of enforcing indentation instead of adding "end"s. Personally I just want a statically typed language with enforced indent as syntax.
Funny, the forced indentation is what I hate about Python. If you think a missing semicolon can be hard to catch, don’t ever think about a missing whitespace :p
The end keyword really isn’t a big deal for me. I find it to be a good way to easily spot the end of a method. But if you wouldn’t like it I’d still find it a good compromise to avoid syntax issues due to whitespace.
Same and agreed, especially if you keep your functions small and focused as you should. 3-5 indents is nbd to keep track of, and if you need more than that… No you don’t, refactor.
I’ve had way more hangups with brackets then indentation, personally, not that either is a super frequent issue, but I’m indenting anyway, so brackets are redundant and just another thing I have to keep track of
That’s just Algol instead of B. Most languages use the one or the other, then there’s sexpr-based languages (lisp, scheme), lua (technically Algol but not needing semicolons while also not needing newlines so it’s definitely special), and layout syntax (Haskell, or, if you want a bad implementation, python).
Basically, when you leave out the ‘{’ then Haskell uses your intendation to insert ‘;}’ on later lines between the leading whitespace and the first token.
There some really old Haskell code out there that lines up the ‘{;}’ characters on the left under block-introduction keywords.
It’s not just old Haskell code that’s how you write Haskell if you want explicit braces. Well, mostly generate, but it’s still the idiomatic formatting (and when you generate you always generate braces because it’s easy to get layout subtly wrong when generating).
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.