Clean Code: A Handbook of Agile Software Craftsmanship

11 Aug 2008

by Robert C. Martin

An extremely pragmatic method for writing better code from the start, and ultimately producing more robust applications.

Pages: 431

Publisher: Prentice Hall

Overall: 60% of the 388 mentions are positive, 33% are neutral and 7% are negative.

buy now

388 mentions sorted by:
  • There are books and articles on the subject (recommendations welcome). A good advice is to keep in mind (or imagine) that the code will have to be changed. Maybe in a year; maybe not by you - this is very common in "real life". For example; of you have 128 of something to process or a limit of 128 that appears often; write N = 128 and then use only N; this way; if/when the limit changes; you'll have to change in one place. Keep code as modular as possible: if there is getting data; processing the data and displaying the data; keep these as separated as possible - no processing during displaying. This way; if/when you'll have to display it otherwise or somewhere else; you'll change the displaying code; but the processing will stay where it was: out of sight; out of mind. Then there's code review; not for the faint of heart; as it's 99% negative feedback; because it lists things that need to be changed and improved and doesn't focus on the good ones. But this is very "real life": you can't get attached to your code; it will be ciritised and it will be deleted; it's a stepping stone and not a work of art. (Take pride in what the project does and the difficulties overcame. It can be a challenge to keep your head up high in this job; since you're always working on the things than need fixing; not the ones that are done and working.) If you want; you can send me a sample to review. Finally; the appropriate xkcd.
    3 points in /r/learnpython by KlaireOverwood | 31 May 2017
  • If you are a person who tries his best to keep his code tidy and readable; I strongly recommend reading this book: If I recall correctly; their suggestion is to keep functions as short as a few lines and focus mostly on how you name them. But the general guideline is the same as most of the comments here mention: a function must do a single thing. Similarly to single responsibility principle of a class/module: The book is really well written and has helped me a lot in making my code readable (atleast i hope so :) ).
    1 points in /r/webdev by dzhv | 27 May 2017
  • Great job! It's good that you are thinking about this stuff and wanting to have a solid portfolio. I'm on an interview panel for a large tech company. So my feedback is from the point of view of an interviewer: Link to the source code. Put it on github and provide a link. Interviewers will want to easily find the source code and look at it. Make sure you have unit tests Pay attention to the coding standards /best practices. Basically all the stuff mentioned in Clean Code Always link to to you resume/homepage/linked in so employers can learn more about you
    3 points in /r/learnprogramming by YuleTideCamel | 19 May 2017
  • I know right?! I was like that as well; until I had been enlightened. Here is my new bible:
    1 points in /r/ProgrammerHumor by simonced | 16 May 2017
  • The locals approach was included in my experimentation as follows: def auto_assign_arguments(instance): localItems = inspect.stack()[1].frame.f_locals.items() vars = {k:v for k;v in localItems if k not in ['self'; 'args'; 'kwargs']} instance.dict.update(vars) class Simple: def init(self; arg1; arg2; _private; *args; kwarg1=False; *kwargs): auto_assign_arguments(self) However; it did not work for all possible argument combinations; and would have required a similar structure to the posted solution; since my primary goal was to handle all cases.  The [locals; positional/keyword args only] approach is definitely more performant; but this code's intention is boilerplate reduction for rapid prototyping.  If nanosecond-level performance becomes a concern; you can always go back & write out the assignments manually.   > Achieves the same thing without mountains of boilerplate I'd argue that it's not boilerplate at all.  It's a decorator; with helper functions; which handles its intended task appropriately.  The definition of boilerplate is phrases or units of text used repeatedly; so I find any code that is unabstracted; such as: vars = {k:v for k;v in locals().items() if k not in ['self'; 'args'; 'kwargs']} self.dict.update(vars) to be actual boilerplate; VS the much more concise/descriptive auto_assign_arguments (whether in decorator or function format).  The code behind the scenes is written once; so it is; by definition; not boilerplate.   > The idea being you ignore args/kwargs so as not to set off any rm -rf / situations I'd be interested to see if someone could break the code I posted.  To the best of my knowledge (and included tests); it seems like it handles all possible scenarios without fail.   > I had a hard time reading what you wrote I've been working through Robert Martin's Clean Code / Clean Coders material; and my current focus has been around the single responsibility (EG: small functions) and descriptive naming principles. The [execution; high-level overview] of the _assign_args function is at the bottom; after all of the helper function declarations: if(KEYWORD_DEFAULTS ): assign_keyword_defaults (parameters=POSITIONAL_PARAMS; defaults=KEYWORD_DEFAULTS) if(KEYWORD_ONLY_DEFAULTS): assign_keyword_only_defaults(defaults=KEYWORD_ONLY_DEFAULTS ) if(args ): assign_positional_args (parameters=POSITIONAL_PARAMS; args=args ) if(kwargs ): assign_keyword_args (kwargs=kwargs ) if(VARIABLE_PARAM ): assign_variable_args (parameter=VARIABLE_PARAM; args=args ) which IMO is pretty straight-forward.  Each one of those helper functions is only 2-3 lines; so they should be pretty easy to understand individually.  They're arranged in that particular order to ensure proper assignment of each type of argument.
    2 points in /r/Python by enteleform | 13 May 2017
  • Clean Code
    1 points in /r/ProgrammerHumor by Brocccooli | 10 May 2017
  • Disclaimer: I'm an undergraduate and don't know shit. I think the best way to learn is from the small parts; up. So; first learn a structured (preferably OO) programming language. Python will do; but I'd recommend something with compilation and static typing. Python is great for scripting and has its purpose; but designing and implementing a complex system in Python is a nightmare. After learning that; learn how to write your classes; methods and just generally structure your code better. I highly recommend Clean Code for that. After understanding good class design and code structure; start learning about higher-level concepts on how those well-defined classes should communicate with each other and be decoupled. Important concepts to learn are coupling and cohesion; polymorphism; inheritance; etc. All the basic OOP concepts. From there; you can move onto architecture. The book I used in my courses was System Analysis and Design; but there could very well be better ones out there. Edit: Oh; and it's helpful to at least be knowledgeable of common design patterns. I really like SourceMaking's approach and explanations; but once again there's tons of good resources out there.
    1 points in /r/softwaredevelopment by NowImAllSet | 08 May 2017
  • [For coding best practices : ] ( Maybe you don't need to follow this to the T but it's helpful overall. [For when you are stuck / architecting your program: ] ( Explain your code/talk through exactly what you are doing to a rubber duck or willing participant. A lot of times saying it out loud and explaining your code will help you find any holes to think about/fix.
    1 points in /r/OSUOnlineCS by Teimoso | 07 May 2017