Kamran Ayub is a technologist, speaker, and Pluralsight author and specializes in building full-stack solutions with a focus on modern web technology and cloud native architecture.
I still need to read PP but I am halfway through Clean Code. I do not endorse the author but the tactics in the book resonated with me.
The three that stood out, in summary:
A module or file should read like a top down narrative, where the reader finds their self more in the low level details by the bottom of the file.
Functions or methods should operate at one level of abstraction. This was a different way I had never thought about SRP (single responsibility principle) before. It means you should be able to understand the function without needing to know it's details, and this goes with the first point, as every step in the implemention is a level deeper until you reach the end.
Comments are failures to communicate intent through code. Always question yourself when about to write a comment. Can I rename this function or variable, or extract this logic into a named function, to better communicate my intent?
Just these three ideas have really enhanced the way I write code and do my code reviews with my team.
I think that I've read Clean Code sometime in the last few years, but I don't remember anything from it :|
Anyway, those are all valid points, but I would add an exception to the third one - comments are essential, in my opinion, but they should not tell what the code is doing (code should be doing that in a readable way) but why is code doing that. Why in this context should be business or some domain requirement, something that's on a higher level than code but affects its nature. Still, if this can be told through code alone, leaving a comment would induce an additional cognitive load on the reader, so it's not a hard rule.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I still need to read PP but I am halfway through Clean Code. I do not endorse the author but the tactics in the book resonated with me.
The three that stood out, in summary:
A module or file should read like a top down narrative, where the reader finds their self more in the low level details by the bottom of the file.
Functions or methods should operate at one level of abstraction. This was a different way I had never thought about SRP (single responsibility principle) before. It means you should be able to understand the function without needing to know it's details, and this goes with the first point, as every step in the implemention is a level deeper until you reach the end.
Comments are failures to communicate intent through code. Always question yourself when about to write a comment. Can I rename this function or variable, or extract this logic into a named function, to better communicate my intent?
Just these three ideas have really enhanced the way I write code and do my code reviews with my team.
I think that I've read Clean Code sometime in the last few years, but I don't remember anything from it :|
Anyway, those are all valid points, but I would add an exception to the third one - comments are essential, in my opinion, but they should not tell what the code is doing (code should be doing that in a readable way) but why is code doing that. Why in this context should be business or some domain requirement, something that's on a higher level than code but affects its nature. Still, if this can be told through code alone, leaving a comment would induce an additional cognitive load on the reader, so it's not a hard rule.