Skip to content

Instantly share code, notes, and snippets.

@wojteklu
Last active April 13, 2024 14:50
Show Gist options
  • Save wojteklu/73c6914cc446146b8b533c0988cf8d29 to your computer and use it in GitHub Desktop.
Save wojteklu/73c6914cc446146b8b533c0988cf8d29 to your computer and use it in GitHub Desktop.
Summary of 'Clean code' by Robert C. Martin

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.


General rules

  1. Follow standard conventions.
  2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
  3. Boy scout rule. Leave the campground cleaner than you found it.
  4. Always find root cause. Always look for the root cause of a problem.

Design rules

  1. Keep configurable data at high levels.
  2. Prefer polymorphism to if/else or switch/case.
  3. Separate multi-threading code.
  4. Prevent over-configurability.
  5. Use dependency injection.
  6. Follow Law of Demeter. A class should know only its direct dependencies.

Understandability tips

  1. Be consistent. If you do something a certain way, do all similar things in the same way.
  2. Use explanatory variables.
  3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
  4. Prefer dedicated value objects to primitive type.
  5. Avoid logical dependency. Don't write methods which works correctly depending on something else in the same class.
  6. Avoid negative conditionals.

Names rules

  1. Choose descriptive and unambiguous names.
  2. Make meaningful distinction.
  3. Use pronounceable names.
  4. Use searchable names.
  5. Replace magic numbers with named constants.
  6. Avoid encodings. Don't append prefixes or type information.

Functions rules

  1. Small.
  2. Do one thing.
  3. Use descriptive names.
  4. Prefer fewer arguments.
  5. Have no side effects.
  6. Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag.

Comments rules

  1. Always try to explain yourself in code.
  2. Don't be redundant.
  3. Don't add obvious noise.
  4. Don't use closing brace comments.
  5. Don't comment out code. Just remove.
  6. Use as explanation of intent.
  7. Use as clarification of code.
  8. Use as warning of consequences.

Source code structure

  1. Separate concepts vertically.
  2. Related code should appear vertically dense.
  3. Declare variables close to their usage.
  4. Dependent functions should be close.
  5. Similar functions should be close.
  6. Place functions in the downward direction.
  7. Keep lines short.
  8. Don't use horizontal alignment.
  9. Use white space to associate related things and disassociate weakly related.
  10. Don't break indentation.

Objects and data structures

  1. Hide internal structure.
  2. Prefer data structures.
  3. Avoid hybrids structures (half object and half data).
  4. Should be small.
  5. Do one thing.
  6. Small number of instance variables.
  7. Base class should know nothing about their derivatives.
  8. Better to have many functions than to pass some code into a function to select a behavior.
  9. Prefer non-static methods to static methods.

Tests

  1. One assert per test.
  2. Readable.
  3. Fast.
  4. Independent.
  5. Repeatable.

Code smells

  1. Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
  2. Fragility. The software breaks in many places due to a single change.
  3. Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
  4. Needless Complexity.
  5. Needless Repetition.
  6. Opacity. The code is hard to understand.
@lemieuxhelmsi
Copy link

Very informative! If did something a certain way and do all similar things in the same way as concrete wall contractors Dallas!

@SHAM-BHU123
Copy link

Nice

@luisdatec
Copy link

Thanks. I used it as a reference to improve my codes from now!

However, I will read that book.

@NidusUmbra
Copy link

Hello Excuse me, do you know me? I am sorry.

On Fri, Mar 3, 2023 at 4:22 AM NidusUmbra @.> wrote: @.* commented on this gist. ------------------------------ Turns out paying too much attention to the "cleanliness" of your code can have significant drawbacks. Such that it may become indefensible. https://www.youtube.com/watch?v=tD5NrevFtbU — Reply to this email directly, view it on GitHub https://gist.github.com/73c6914cc446146b8b533c0988cf8d29#gistcomment-4490308 or unsubscribe https://github.com/notifications/unsubscribe-auth/A5BVSDB5VI2O7DGOAIUABFTW2GZ55BFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFQKSXMYLMOVS2I5DSOVS2I3TBNVS3W5DIOJSWCZC7OBQXE5DJMNUXAYLOORPWCY3UNF3GS5DZVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVA2DANZRHAYDQM5HORZGSZ3HMVZKMY3SMVQXIZI . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

No. These reply notifications don't work like one would intuitively think. I did not reply to you nor did I quote you. You get a notif when anyone answers the main thread. Cheers.

@ChrisLuckComes
Copy link

Thanks very much! I'll read that book carefully sometime

@kehiy
Copy link

kehiy commented Jun 21, 2023

very very useful !

@tbrehuescu
Copy link

https://kingadesign.com/clean-code-poster-free-download?fbclid=IwAR2p9y7Rf5gyH586sXYxp2dgoA3kWvRlLO5jfgeHlj77k1Y94qM1grjdW84

Hi, the link is not working. I got: Something went wrong!
Page not found.
. Thanks!

@tbrehuescu
Copy link

@JahanzaibIlyas
Copy link

So helpful

@marcegarba
Copy link

Thank you!!!

@Unbreak4ble
Copy link

I would like to contribute to this amazing Clean Code hints by one that I noticed it's possible to be done and nobody talks about...

Conditional Simplification

You can always turn a complex conditional into a simpler one through the Propositional Logic rules
Screen Shot 2021-11-16 at 21 27 24

  • References
  1. De Morgan
  2. Tautology
  3. Propositional Logic

Inspired by Robert C Marin's book: Clean Code

Or you could just paste an "obfuscated" ((a && b) || (b &&c) || (!a && !c)) version of your condition into https://www.wolframalpha.com/ and let it do the work. (Minimal forms)

That's work. But if "setting" is null when hideOnGrid is false, it's generate exception.

@jomisacu
Copy link

I would like to contribute to this amazing Clean Code hints by one that I noticed it's possible to be done and nobody talks about...

Conditional Simplification

You can always turn a complex conditional into a simpler one through the Propositional Logic rules
Screen Shot 2021-11-16 at 21 27 24

  • References
  1. De Morgan
  2. Tautology
  3. Propositional Logic

Inspired by Robert C Marin's book: Clean Code

Or you could just paste an "obfuscated" ((a && b) || (b &&c) || (!a && !c)) version of your condition into https://www.wolframalpha.com/ and let it do the work. (Minimal forms)

That's work. But if "setting" is null when hideOnGrid is false, it's generate exception.

You could define additional vars to add semantic. Ex.

const mustHideOnGridByColumn = column.hideOnGrid;
const mustHideOnGridBySetting = setting && setting.hide_on_grid;

return !(mustHideOnGridByColumn || mustHideOnGridBySetting);
 // or: return !mustHideOnGridByColumn && !mustHideOnGridBySetting

This way is very clean and improves readability

@jhoeljp
Copy link

jhoeljp commented Aug 8, 2023

Very helpful!

However heres a video challenging the efficacy of 5 design rules of clean code: https://youtu.be/tD5NrevFtbU

@JohannesJacop
Copy link

I am not a programmer myself. So, I haven't read the book myself (although I knew about it for sure 😉) and I read the summary here now for the first time—and I just realized, the recommendations actually apply to quite a lot of other things as well!

So, for all non-engineers, it's worth the read! 💡 Thanks for sharing. 👍

@pedroluiznogueira
Copy link

I would like to contribute to this amazing Clean Code hints by one that I noticed it's possible to be done and nobody talks about...

Conditional Simplification

You can always turn a complex conditional into a simpler one through the Propositional Logic rules
Screen Shot 2021-11-16 at 21 27 24

  • References
  1. De Morgan
  2. Tautology
  3. Propositional Logic

Inspired by Robert C Marin's book: Clean Code

Or you could just paste an "obfuscated" ((a && b) || (b &&c) || (!a && !c)) version of your condition into https://www.wolframalpha.com/ and let it do the work. (Minimal forms)

That's work. But if "setting" is null when hideOnGrid is false, it's generate exception.

You could define additional vars to add semantic. Ex.

const mustHideOnGridByColumn = column.hideOnGrid;
const mustHideOnGridBySetting = setting && setting.hide_on_grid;

return !(mustHideOnGridByColumn || mustHideOnGridBySetting);
 // or: return !mustHideOnGridByColumn && !mustHideOnGridBySetting

This way is very clean and improves readability

This is by far one of the best things I’ve started doing for a while.

Usually boolean conditions are a representation of a behavior, meaningful names will always help your code read like a story.

That way just by reading the variable name you get the problem statement.

For example:

if (isReadyToReceiveMessage) {…}

Of course one should be careful to not create misleading variables that don’t mean what the condition represent. (tests help with that semantics).

@Victorcorcos
Copy link

Victorcorcos commented Sep 12, 2023

@Victorcorcos if setting is null or undefined the old code is working but not the new code, or am I missing something ?

The new code will work, because this is applied:

  1. Avoid NPE on q by using || {}
  • Before
setting = fieldSettings[column.foreignAttribute] || fieldSettings[column.description]
  • After
setting = fieldSettings[column.foreignAttribute] || fieldSettings[column.description] || {}

So, in case setting is null/undefined, it will be {}, which won't cause NPE.

→ We can't see that on the picture, but that || {} was the change on that specific line

@SpringfieldC
Copy link

Interesting

@M1SHANIA
Copy link

Can I download this book somewhere for free? TY<3

@philipvella
Copy link

thanks for this @wojteklu 👍

@Dariushdragon
Copy link

it helps a lot for me thank you.

@hassan-mohagheghian
Copy link

sounds great, thank you!

@arkadiusjonczek
Copy link

❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment