181–190 of 395 posts
Earlier quoted context omitted.
In c++ you choose the default so I'm not sure it should be lumped in with the others.
In the literal sense private is default though. I wonder why. Lexical sorting of private, protected and public? It makes almost no sense to have all private class fields and methods. The only thing I can think of is fat handles with friend classes or functions.
So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well verse…
Earlier quoted context omitted.
“Effortless to follow” is eloquently put. When I interview candidates during recruiting I often ask the open ended question “what is good code for you” as it gets people talking. There is rarely a wrong answer. Usually, there is a difference in answers between more junior and more senior programmers. More senior candidates focus more on the readability & maintainability, while more junior programmers focus on accurac…
> When I interview candidates during recruiting I often ask the open ended question “what is good code for you” as it gets people talking. There is rarely a wrong answer. I don't mean to be snarky, but if there is rarely a wrong answer to this question, then it doesn't sound like a good interview question to me. Having been through a bunch of interviews, I don't understand the obsession over clean code. I would under…
No worries. I should’ve included it more clearly in my comment. I use the question to gauge seniority and experience to help determine salary proposal.
As I mention, there is typically a difference in the answer of a junior programmer (or someone who’s used to being a solo-dev) vs a senior dev that worked on larger projects with bigger teams.
Moreover, the question is about _good_ code, not clean code.
So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well verse…
It is funny to mention Fabrice Bellard on a topic about clean code when one of his many achievements is to have 3 winning entries in the IOCCC.
Clean code minimizes these measurements.
To minimize variable count I can use ternary expressions. To minimize indentation level I think carefully about early returns or extracting blocks of code to functions that do nothing if condition is true (early return).
To minimize grokking time, I revisit old code I've written and measure the time it takes me to understand it. It turns out it correlates quite a lot with line, variable, and token count, indentation level :D
Clean code as commonly defined is far away from any measurable metrics. That's why one might say that it does not exist.
Earlier quoted context omitted.
It is funny to mention Fabrice Bellard on a topic about clean code when one of his many achievements is to have 3 winning entries in the IOCCC.
Haha true true ! Maybe he is a cross-spectrum coder ?
Don't get me wrong, he's a fucking wizard. He's Mozart when the most talented of us can only ever hope to be Salieri. But part of that is, he dashes off brilliant code without much thought to its maintainability, then leaves for the next project.
Earlier quoted context omitted.
Back in university I had an experience that was really instructive. For a project we had to write a program that differentiates mathematical equations. I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created. Unfortunately I fi…
Yeah this just hasn't been my experience. If you're working on a house you measure twice and cut once because the cost of reworking physical materials is a lot more expensive than the cost of doing a second measurement. If you could delete half your house and re-build it at zero cost, it might be more valuable to just go for the first attempt and learn from it rather than trying to do everything in theory up front. I…
I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was pretty expensive
So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well verse…
The more code I've written, the less I care about code quality. I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be: - I minimize interdependencies (changing a line of code should not affect something un-related) - I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/des…
I sort of agree with this, but not quite. I care about code quality, but not code aesthetics. Aesthetics was really important to me when I was younger and more inexperienced. I wanted my code to be pretty, and wouldn't be happy until I found an algorithm or abstraction that met my definitions of pretty code. I would polish it until it was shiny. I would even align my variable names to be pleasing to the eye.
20 years later, I know there are things that will just never quite look neat. FizzBuzz is a pretty accessible example of this phenomenon, but most non-trivial algorithms have that to some extent.
> Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem in the most pragmatic way. Maybe that's hard-coding a lot of things. Maybe that's having a small amount of repetition here and there. Maybe it's writing one long function with 1000 lines.
> After that it's all about continuous improvement. You spend your time solving the problem, and when your code becomes hard to work on, you spend time improving your code to make it easier to work on by cleaning things up, and adding sensible abstractions which solve the problems you actually have.
I too am firmly in the camp of write code first, refactor into a maintainable solution when it works. Maybe it's tacit experience refactoring messy code, sort of knowing in the back of your head how it will shape up when refactored.
Earlier quoted context omitted.
> If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…
These are minor inconveniences relative to the massive benefits all these techniques bring to your codebase. "Go to implementation" shortcut is a thing and solves the first 2. "One assert per test" -> just test one "concept" per test, not literarily 1 assert statement per test. IE : assert(loc.x == 10.3) assert(loc.y == 10.4) assert(loc.z == 10.5) is absolutely fine (even you could do it in 1 assert).
In any case, "concept" being such a loosely defined thing would render the rule a bit pointless.
There is something deeper behind this rule but think he fucked up articulating what it was.