311–320 of 647 posts
This code reminds me of why ML-like languages with Maybe-style types and case expressions that generate compiler errors for missed alternatives are good. I bet rewriting this in OCaml or Haskell would lead to tighter code and might even unearth a couple possible states that haven't been accounted for.
You don't really need functional languages to have those features, as swift, kotlin and others show.
As an example of what I mean, look at some places where the if chunk is as big as the else chunk. By the time you are at the else, you might have to scroll back a ton to get to what it is you are in the else of.
Now, yes, to an extent, you could split this between functions. Such that you could have:
if foo {
doSomething
} else {
doSomethingElse
}
if foo {
>
} else {
>
}
Not a panacea, but can be quite powerful.
I love this! It's the "jazz music" of software development. Something which breaks all the "rules" but does so purposefully and explicitly so that it can become better than the "rules" allow. A naive look at this and my head is screaming that this file is way too big, has way too many branches and nested if statements, has a lot of "pointless comments" that just describe what the line or few lines around it is doing,…
About five years ago I worked on a codebase with a similar bit of code. It wasn't nearly this big, but it was branchy, procedural, and verbosely commented. I didn't write the initial version but worked on it quite a bit and learned to appreciate the advantages of the style for the nasty bit of logic it implemented. I ended up having to vigorously defend it against another developer's half-cocked attempt at "refactori…
Earlier quoted context omitted.
> I love this! It's the "jazz music" of software development. Something which breaks all the "rules" but does so purposefully and explicitly so that it can become better than the "rules" allow. I kind of see it as the opposite: “space shuttle style” is code that adheres to heavyweight rules that most software development has abandoned in favor of a more improvisational style. But in either case it illustrates that co…
I've had this latent thought for a while that I'm finally putting to words: The complexity goes somewhere. It's either into lots tests, or it's into something like shuttle style with lots of comments, or it's into a huge QA department, or it's into the type system / DB schema. It could even be going into the org structure! But something, somewhere is handling the complexity and it is doing so as a partial function to…
Earlier quoted context omitted.
Martin Fowler of the Agile world, and Garret Smith of the Erlang community, are both excellent programmers whom I respect, and they both take the approach of breaking code into lots of extremely small functions. Having tried that style, I notice that I don't particularly favor it, and for the very reason you site: the code is no longer all in one place. I've switched to moderately sized methods/functions with comment…
I assume everyone who splits code into smaller pieces use modern IDEs that makes it trivial to navigate to functions by clicking them etc. I say this because I'm always astonished by the number of "modern" programmers who refuse to use IDEs.
Although I think this is great, this reminds me of a talk Bryan Lunduke did where he says CS/software development is not a profession yet. I love the flexibility software devoplmentgives to every cs, programmer, developer but when you think more about it, that is not the same for other jobs/professions. Professions have standard guideline, procedures to follow. Everyone is doing any language they want, design pattern…
That might be true if you live in a cave but when you are working on a team of 6-8 people with a team lead then basically none of that is true and you are forced to follow others' decision and everything is decided for you (instead of you to make decisions) no matter if you like it or not.
Of course some might say but then you have to make compelling arguments to raise your concerns and being heard but that's beyond the point and that's politics that most people (including me) despise. As a software engineer your only choice to make those decisions you mentioned is that you are a manager of some sort or you work completely alone.
And for some reason most developers accept this hierarchical relationship in their daily professional life but still pretend that they are allowed to make decisions by themselves instead of pointing out the implicit forces which rule their daily lives.
And I like to call out this line of thinking because it is pushing this liberal agenda that you are the sole reason for your luck or failure which is not true at all. Not even close to reality.
Actually many thought leaders in our industry for example Uncle Bob anticipate that our industry MUST and/or WILL be regulated (if by self-imposed regulation or external one is again beyond the point) otherwise the whole industry would lose credit. And I fully agree with that.
Not only because of credibility reasons but also because it makes the implicit subordinate relationship that most developers are blissfully unaware of, more explicit.
Earlier quoted context omitted.
I don't understand the objection to having more, smaller files, at least in Go where they can all be in the same package. Once two functions are too far apart to be on screen at the same time, jumping back and forth between two functions in the same file doesn't seem any easier than switching between different files. If anything, switching between two different files is easier since they each get an editor tab. On th…
For me, it's less about number of files than it is "hoeany files do I have to open to figure out how something works? How many levels of indirection do I have to keep in my head?" I started out writing low-ish level code. Motion control, image processing, digital imaging, and the application level code that coordinated it all. I've steadily moved up the abstraction tree over the last 13 years and there's one thing I…
Earlier quoted context omitted.
Maybe a loose correlation? Highly commented code was probably not written under tremendous time pressure; uncommented code can go either way. Wrongly commented code is painful, though. And then there's something I recall running into, a decade ago: using namespace std; // using namespace standard
I always wondered what std stood for /s
It wasn't even "using standard namespace"...
I see a lot of comments mentioning various versions of the following: - "It's the "jazz music" of software development." - "...breaks all the "rules" but does so purposefully..." - "this is irreducibly complex, and cannot be split into multiple files" - "that smallness-of-file or smallness-of-function is not a target to shoot for" I am wondering: can't all the above statements be said in defence of any poorly enginee…
Can everyone play jazz? No.
Yes.