91–100 of 115 posts
There is an entire discipline on the idea that the effort to make code easily read/understood will result in source code which is easier to maintain and write: https://literateprogramming.com/ (or if that's off-line, see: https://en.wikipedia.org/wiki/Literate_programming ) and published books which exist so that folks can read the source code of programs: https://www.goodreads.com/review/list/21394355-william-adams.…
Earlier quoted context omitted.
I think you are not reasoning correctly here Adding features to a code means it was incomplete. Misunderstanding input/output usually means it is poorly documented or lacked a good API. A good API works at the surface (in/out) and not in the volume. Really good code solves a problem completely. I have worked with such code and yes almost nobody ever goes into this code (and makes changes).
> Adding features to a code means it was incomplete. That definitely implies code can't be good if needs change, which makes no sense to me.
This does not impact readability or the idea of "good code" in my opinion.
You could have an application that is missing features which still contains examples of "good code". Learning about "good code" by reading the source code of this application won't really give any direct hints of missing features...the granularity is different.
In the real world, code is read often and for many reasons. The main ones I can think of are: 1) To understand the system without necessarily wanting to change anything. This is common with new employees or anyone wanting to learn more. 2) The system often needs tweaks, bug fixes or new features. Each of these normally requires that the code in question is read by several people several times. 3) The architecture is…
I agree with the first one but the other 2 are basically what the author is speaking out against. Some change/rework is unavoidable, but if code is good, then it should be relatively rare. Modularity isn't sufficient for code to be good. It's difficult to have truly 'loose coupling' without 'high cohesion'; each module should have distinct and well-defined responsibilities. My test for high cohesion is the question:…
The compiler will probably optimise those extra lines out, but if not, I consider it a cost worth spending to make my life (or somebody else's life) easier in the future.
Earlier quoted context omitted.
I would argue that lots of useful code is an utter dumpster fire internally. That doesn't mean we shouldn't strive to do better. Useful | | Bad-------Good | | Not Useful
Not useful code is always bad, because you never had to write it. It is just a waste.
Earlier quoted context omitted.
> Adding features to a code means it was incomplete In practice this isn't true. The code may have been perfect and complete according to the business requirements of 1 month ago. But the business requirements of 1 month ago and today are often completely different.
This falls outside of my experience. I am systems or "backend".
Earlier quoted context omitted.
I agree with the first one but the other 2 are basically what the author is speaking out against. Some change/rework is unavoidable, but if code is good, then it should be relatively rare. Modularity isn't sufficient for code to be good. It's difficult to have truly 'loose coupling' without 'high cohesion'; each module should have distinct and well-defined responsibilities. My test for high cohesion is the question:…
That's kinda unrealistic. It's okay to expect that if you change the requirements for A, there should be no changes in the code of B. It's not okay to expect that if you change the requirements for B, then there should be no changes in the code of B.
Most of my refactoring only affect the trunk of the code. I try to have all the business logic for a program or service represented in a single file. If the file gets too big, I create new modules 'branches' and move the most generic logic to those branches. My top level file tells the full story of the program/service. Anyone can open that file and, based on the module names and method names that are being called, they can figure out what happens and when. All the events, endpoints, logging, access control and other externally observable behavior is wired together in that file.
If the file has been abstracted to the maximum amount possible (with all generic functionality moved to branch modules) and it's still too big, it may be time to switch to a micro-service architecture. Break up the trunk into 2 parts and we basically end up with 2 apps/services. This rarely happens though. With the right level of abstraction, you can fit a massive amount of user functionality in a single main file. By the time the main file's code becomes overwhelming, the application's UX becomes overwhelming for the end user too... Time to split up into multiple apps.
Think of how complicated UX would be if a video-editing software tried to support image editing as well (e.g. to make fancy title screens or UI overlays). It would become too much for the user. Just make two different applications; one for video editing, one of the image editing. You can integrate them in a seamless way, but they should be different apps.
Earlier quoted context omitted.
> Adding features to a code means it was incomplete. That definitely implies code can't be good if needs change, which makes no sense to me.
Missing feature implies an error at the Requirements level. This does not impact readability or the idea of "good code" in my opinion. You could have an application that is missing features which still contains examples of "good code". Learning about "good code" by reading the source code of this application won't really give any direct hints of missing features...the granularity is different.
(also couldn't help but think "this is not the code you're looking for. move along.")
I don't think the author has worked on long-lived projects. Eventually, all code is revisited because there's always shit to get done.
Exactly my thoughts. The reason why good code is code that is easy to read, is because products evolve, and so does the code. Suddenly the taxonomy of that enum starts to shift, and the name that was perfect yesterday does not make sense tomorrow. These changes happen gradually and a basic acceptance of the code base not being on par with the product understanding is necessary in order to have any kind of velocity on…
"good code is easy to read" - that does not work.
I can write a bubble sort instead of quicksort and that code will be bad.
Maybe you can do the same thing with privacy policies. Most complicated privacy policies are bad, so they make them hard to read so that people do NOT understand them and give up.
But you could have a privacy policy that is bad and easy to read. "We can do anything".
I think good code is primarily easy to read. And I think it should not attract attention through bad behavior, so it should additionally not come under scrutiny for that.