We have a broad understanding of how to structure and write software. These ideas have been collected together in books. I refer to books like Code Complete, Debugging the Development Process, Clean Code, Refactoring, Programming Pearls, Beautiful Code, and so on. Then there are the language specific books. I don't believe you can craft well written C++ without reading Scott Meyers' books (or having absorbed the same knowledge from others), for example. Even the much maligned Design Patterns, which has been turned into the truly dreadful design by pattern, helps us to think about how to structure code.
I can't type it all in a post. But we are talking about modularity and extensibility. Decoupled code, so you can make changes here that don't break something over there, and so you can easily move code from one project to another. Well commented code - where 'well' means the author takes the use of the code into account - some deeply internal function named ComputeAverageSalary probably doesn't need much in the way of extra comments, anda top level api call to a framework being used by thousands needs a lot of documentation. Well structured code. The if statements make sense. They are not deeply nested. logic is not duplicated, or contradicted when it is nested, because that always leaves you scratching your head as to the purpose of the author(s), and clueless as to how to add code.
So, back to the question, why would you bet that? I've opened plenty of 15 year old code that is good to beautiful. This is not an arbitrary judgement of "oh, OO good/bad", nor an reactionary "it wasn't written by me, so it must be bad".
I do consider myself a pretty clean programmer, but I learned it by observing the code of others, reading a lot of books, and relentlessly applying a critical eye on everything I write and others write. All borne not on some arbitrary judgement, but from recognition of how quickly/slowly I can grok a piece of code, how easy it is to find and fix bugs, how easy to add features, and so on. In some code bases that is all fairly straightforward, and in others it is impossible - any fix or change has so many side effects that you need to add 50 if statements strewn about 50 files, in code already filled with if statements, and your if statement break about 15 undocumented assumptions about the behavior of the tightly coupled code.... that, my friends, is shit.
> relentlessly applying a critical eye on everything I write and others write
Honestly, I believe that this is one of the best habits I've developed at my current workplace. We use Code Collaborator (a code review tool) for about 90% of all commits; I like using to get at least one pair of eyes on my code, but even further, I only even send out a review after I've gone through my own diff with a fine-toothed comb.
We have a broad understanding of how to structure and write software. These ideas have been collected together in books. I refer to books like Code Complete, Debugging the Development Process, Clean Code, Refactoring, Programming Pearls, Beautiful Code, and so on. Then there are the language specific books. I don't believe you can craft well written C++ without reading Scott Meyers' books (or having absorbed the same knowledge from others), for example. Even the much maligned Design Patterns, which has been turned into the truly dreadful design by pattern, helps us to think about how to structure code.
I can't type it all in a post. But we are talking about modularity and extensibility. Decoupled code, so you can make changes here that don't break something over there, and so you can easily move code from one project to another. Well commented code - where 'well' means the author takes the use of the code into account - some deeply internal function named ComputeAverageSalary probably doesn't need much in the way of extra comments, anda top level api call to a framework being used by thousands needs a lot of documentation. Well structured code. The if statements make sense. They are not deeply nested. logic is not duplicated, or contradicted when it is nested, because that always leaves you scratching your head as to the purpose of the author(s), and clueless as to how to add code.
So, back to the question, why would you bet that? I've opened plenty of 15 year old code that is good to beautiful. This is not an arbitrary judgement of "oh, OO good/bad", nor an reactionary "it wasn't written by me, so it must be bad".
I do consider myself a pretty clean programmer, but I learned it by observing the code of others, reading a lot of books, and relentlessly applying a critical eye on everything I write and others write. All borne not on some arbitrary judgement, but from recognition of how quickly/slowly I can grok a piece of code, how easy it is to find and fix bugs, how easy to add features, and so on. In some code bases that is all fairly straightforward, and in others it is impossible - any fix or change has so many side effects that you need to add 50 if statements strewn about 50 files, in code already filled with if statements, and your if statement break about 15 undocumented assumptions about the behavior of the tightly coupled code.... that, my friends, is shit.