Today, Venkat Subramaniam gave a very interesting speech on the topic of clearing the code odor. Here are some of my recorded words.
Why do we need quality code?
- The agile development method is used to cope with the feedback information that requires a lot of code changes.
- If the program does not use a good expression, the program will be difficult to read, difficult to maintain, and difficult to modify.
What is code odor?
- Code odor is a kind of bad smell caused by poorly written code, a kind of feeling where a program will be faulty
- Odor is more from intuition than a well-documented standard. When you see code with a taste, you will "feel"
- If you do not clear the odor, you will get used to it soon and no longer notice it.
- Code with bad smell can be written in any language: even in the simplest and safest language, you can make stupid things that can only come up with a genius :)
- We often do not realize that we are writing very bad code, and we often need to point this out from outsiders.
- Edge note: If you don't want to criticize someone's program, don't say "too stupid", say "Oh, this is very interesting .... Is there a better way, you know"
Repeated code
- Will cause the same errors in multiple places in the program
- India guy: We modify the same error every two months.
- Venkat: Have you removed the duplicate code?
- India guy: You said this method is good!
Unnecessary complexity
- Programmers are happy to deal with complicated problems.
- Complexity and terror
Exception Handling
- Q: What is worse than an empty exception capture code?
-
Try {...} catch (exception e ){}
- A: An empty exception capture code with comments!
-
Try {...} catch (exception e) {// is this required? }
- Java exception check: good or not?
- If you don't want to handle an exception, pass it on.
- If you want to catch two exceptions, use two catch Codes instead of writing only one and use the if condition for processing.
Switch Statement & condition determination by type
- The switch statement and the type-based condition judgment can usually be replaced by the polymorphism.
Long Method
- You cannot see the entire method on one screen
- This usually means that a method is responsible for these multiple tasks.
- Difficult to debug
- Cannot be tested
- Difficult to reuse-> cause programmers to copy and paste duplicate code from other aspects of the Method
- Complex conditional statements-> challenge the logic analysis capability of the brain
- Method length: organization induction level is more important than controlling the number of lines of code
Method composition mode
- All statements in the method must be at the same inductive level.
Useless comments
- Make code self-confessed
- Why, not how
- Describe the method representation to be repeated.
- This annotation is equivalent to repeated code writing.
- Comments used to describe this method in a long method with different functions
- Extract functional fragments into small methods & delete comments
- IDE excrement: a placeholder for automatically generated comments by IDE
- Bad comments are usually produced by TDD *
- * (TDD: Threat driven development, threat-driven development) -- youShouldWrite comments for the representation of methods. You should write comments for long methods.
- Notes in the product:
-
// God bless, I really don't know what it means
Variable name
- Use ideographic names
- Do not use a single letter as the name
- Do not use too long names.
Inheritance
- Inheritance is more abused.
- The combination is generally better than the inheritance
- Use inheritance in a one-to-one relationship to meet the liskov replacement principle
- NoImplement method reuse with inheritance
- Delegate is a better choice for reusing methods.
Language of the stick Operator
- This language is more prone to mistakes.
The most smelly code
- Lengthy class
- Repeated code
- Elimination Method
- Unnecessary cast)
- Over-Use design patterns
Code flavor Removal
- Code review!
- Write and proceed as soon as possible
- To be incremental
- To review Test Cases
- Pair Programming
- However, you need to keep the regular changes to your peer. Otherwise, you will get used to your smell and will no longer notice it.
- Peer partner exchange once every two days
Some Design Principles
- High Aggregation
- Low Coupling
- Demeter law [don't tell me, I will notify you]
- Liskov replacement principle
- Let it run first, let it be correct, and then let it be fast
- Development/closure principles
- Reverse dependency
- Single Responsibility Principle
Reference books
- Clean code)
- Code Daquan (code complete) 2
- The pragmatic programmer)
- Practices of an agile developer)
- Smalltalk best practice patterns
- Implementation Mode (implementation patterns) (from @ protoiyer)
Q &
- About using code detection tools, such: This tool is very useful. It allows you to capture very direct problems, so that your code review work focuses on high-level design principles.
- Additional tools on IDE: Do not run them on your own. Make these tools run automatically (or intelligently) in the background)
- Need reconstruction in dynamic languages?: There are not many automatic refactoring tools in dynamic languages, but programmers should still manually refactor them.
- Dynamic Language Design Patterns: Each language has its own model and features. Example: Execute around method mode of Smalltalk
- About mastering multiple languages
- You should be aware of multiple paradigms, different styles, and methods of dealing with a problem.
- The special methods learned by one language are applied to other languages.
- Know the risks of Different Methods
- Programming Language trends: Strong interest in functional programming and mobile device Programming
- About Writing: I have been thinking about various topics in the book for a long time. I will discuss this topic more and learn the essence. When I started writing, I was confident that I could write it
- References: Thinking about literature is very useful, but you should also look at critical thinking articles about how you think (double loop learning ?)
- About Learning: Collaborate, communicate, and discuss with others in the user group. You can't learn anything, but try to narrow down your "you don't know what you don't know" and make it "You Know What You Don't Know"
From http://justjavac.iteye.com/blog/1073139
