- Designing Object-Oriented C++ Applications using the Booch Method. Prentice-Hall. 1995. ISBN 0-13-203837-4.
- Agile Software Development: Principles, Patterns and Practices. Pearson Education. 2002. ISBN 0-13-597444-5.
- Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR. 2008. ISBN 0-13-235088-2.
- The Clean Coder: A Code of Conduct for Professional Programmers.
Here is my summary of the course:
- Software engineers' job is to write code. It is the document of the systems we provide.
- Our work is to do things well. Managers defend the schedule, but our job is to defend the code with equal passion. Quality needs time! They want the truth even if they don't like it.
- Architecture's aim is separation of relevant things from irrelevant ones.
- Yoda was right! Do or do not. There is no try. Decide. Don't lose time.
- The only good measure of clean code is the quantity of WTF per minute while working with this code.
- To keep in shape as a developer you have to practice. Have your programming Kata. Practice regularly solving programming problems. e.g. try developing sorting of an array.
- Always start coding by writing a test. TDD allows you to develop faster. Coverage of code written using TDD is nearly 100%! Maintenance of such code is easier and refactoring can be proven to be correct.
- As test gets more specific, the code gets more general. (Described here: http://cleancoder.posterous.com/the-transformation-priority-premise)
- Long live variables which are searchable should have long names, short live ones should have short names.
- Consider factors methods instead of constructors. Complex.FromRealNumber(23.4) oposed to new Complex(23.4). It is more readable.
- Use methods String.format. It will generate strings with correct end of lines. Just use %n as a line break.
- Don't use brackets if you don't need to.
- Write as small functions as possible. If some lines of function can be extracted as another function, do it. Three, four, five lines for a function is best. It will be more readable.
- Functions should do one thing.
- While refactoring, remember also to change variables' names to correspond with their usage.
- Name of the function can be long. It should describe its action. It is better than adding an additional comment.
- Short function names should be used for bigger scope (like File.open) whereas long function names should be used for small private scopes.
- Use convention for test methods: whenBuyOneBook. Your method will be like a sentence: When action, we assert results.
- Use as small arguments of the function as possible. More than a three are rarely justified.
- Avoid functions with side effects like the ones that change variables of their class, passed arguments or system globals.
- Prefer exceptions to returning error code.
- Extract try catch blocks into functions.
- Clean code doesn't need comments, or only residual ones. Usually we have them too many so IDE changes its color to grey by default. Change color of comments to red, so you will keep them simple, they will strike your eyes.
- Every use of comment represents a failure of expressing ourselves in code. Use comments as a last resort.
- When you write bad code, don't comment it. Clean it!
- Good comments: legal statements, allowed string patterns (like hh:mm:ss), description of intents.
- Avoid TODO comments. Most frequently they are left forever.
- Don't add author in comments. Control system is used for this.
- Don't add html in the comments. It will be harder to read where it is read, I mean in code. If you need it for javadoc then use pre tag.
- Decouple code into many files. Too long files are wrong.
- Keep related variables and functions close to each other
- We prefer 25-40 chars line lengths.
- Team should agree on the formatting rules. Code should look like written by the team not a group of individuals.
No comments:
Post a Comment