Programming is a relatively highly specialized technical profession. There are a large number of programmers around the world. Every day people discuss which programming language is best, what makes a good programmer, and so on. Next, let's look at the most controversial programming opinions.
1. Programmers who don't code for fun in their spare time will never match those who enjoy programming.
I believe that even the smartest and most talented people, if they only treat programming as a job, will never become truly excellent programmers. Those who enjoy programming will work on small projects in their spare time, or tinker with various programming languages and programming ideas.
2. Unit tests don't help write excellent code.
The only reason to write unit tests is to ensure that code that already works doesn't break. Writing tests first or writing code to pass tests is utterly absurd. If you write tests before the code, you don't know what the edge cases are. Although you can make the code pass the tests, problems still occur in unforeseen situations. Moreover, good developers strive to reduce coupling, so new code shouldn't break existing code.
3. The only best practice that applies everywhere is "think with your brain."
Too many people like to chase trendy technologies and try to apply various methods, patterns, and frameworks to unsuitable places. New technologies and the opinions of famous experts do not equal what actually works in real situations.
4. Comments in most code are actually a vicious manifestation of code duplication.
Most of our time is spent maintaining code written by others (or ourselves), and bad, wrong, outdated, and misleading comments are definitely one of the most frustrating things in code. Many people eventually delete them. Effort should be placed on improving code readability, refactoring when necessary, and avoiding idioms and clever tricks. In addition, many textbooks still preach that comments are even more important than code, resulting in large amounts of verbose, pointless comments.
5. There's nothing wrong with relying on Google.
This kind of statement will definitely annoy the learned and erudite. But doesn't everyone need to look things up? A correct answer is a correct answer, whether it comes from some secret book, private teaching, or Google. What matters is truly understanding and delivering successful programming solutions that satisfy clients and bosses.
6. Programmers are not born equal.
Managers often think programmer A == programmer B because they have similar years of experience. In reality, one developer can be ten or even a hundred times more effective than another.
7. I really can't understand why Java is the best first language for university teaching.
First, I believe a first programming language should focus on learning control flow and variables, not objects and syntax. Second, I think people who haven't debugged C/C++ memory leaks can never fully understand the original purpose of Java. Moreover, the natural progression should be from "how do I do this" to "how do I find a library that does this," not the reverse.
8. If you only know one language, no matter how proficient you are, you are still not an excellent programmer.
Some people think that as long as you are proficient in C#, Java, or whatever first language you learned, it's enough. I disagree. Every new language I learn teaches me new programming insights that I can apply back to my work. Anyone limited to one language cannot fully realize their potential. Moreover, lacking curiosity and willingness to explore are not traits of an excellent programmer.
9. It's okay to write garbage code once in a while.
Sometimes for specific tasks, quick and dirty code is enough. Forget about patterns, ORM, SRP (Single Responsibility Principle), and all that.
10. Print statements are an effective debugging method.
I think using output statements like System.out.println to debug code is fine. It's often faster than formal debugging, and you can compare output results from different runs. But be sure to remove these statements before going to production, or put them into logging statements.
11. Your job is to make yourself replaceable.
The software you write should be understandable and maintainable by any other developer with a little time. Software should be elegantly designed, code clear and consistent, formatting clean, documentation appropriate, daily builds, proper version control. If you get hit by a car, fired, or resign, the company should quickly have someone replace you. If not, then you're too tragic. Interestingly, the more you do this, the more valuable you are to the company.
Someone commented under the original post: If you can't be replaced, you can't get promoted either.
12. Getters and setters are extremely overused.
Thousands of people say public fields are evil and should be private with getters and setters. I think there's really no difference, unless the program is multi-threaded, or the accessors contain business or presentation logic (which would be weird). I'm not advocating public fields; I'm just against pretending that wrapping with accessors or properties is encapsulation or information hiding.
13. SQL is also code, please treat it the same way.
SQL is no different from C#, Java, or other object-oriented or procedural languages. Pay attention to formatting, readability, and maintainability.
14. UML diagrams are overrated.
Some diagrams are certainly useful, such as class diagrams for the Composite pattern. But many UML diagrams are worthless.
CSDN editor's note: I remember Robert Martin in "Agile Software Development (C# Edition)" when discussing UML, basically showed a diagram and then said it doesn't seem useful, I haven't used it much... Under the same question there was also a related answer: code == design. Arguing that high-level language code is more effective than UML diagrams and documentation.
15. Readability is the most important aspect of code.
Even more important than correctness. Readable code is easy to fix, optimize, modify, and understand. Other developers can also benefit from it.
16. XML is greatly overrated.
Many people who jumped on the XML bandwagon didn't think it through. XML is fine for web applications because that's what it was originally designed for. For other problem definitions and design ideas, XML should be avoided as much as possible.
17. Software development is just a job.
I love software development. I currently work at a startup, 60 hours a week, with low pay, only because the team is great and the work is interesting. But from a higher perspective, it's still just a job. It's not as important as family, my girlfriend, other friends, happiness, etc. If I had enough money, I'd rather ride motorcycles, yachts, or go snowboarding. Many developers forget that programming is not the ultimate goal; it just provides us the conditions to happily do the most important things in life.
CSDN editor's note: This one seems to contradict item 1.
18. Developers should be able to write code.
Last year I did many interviews. I mainly test people's thinking and how they implement relatively simple algorithms on a whiteboard. I often start with a question like this:
Given that Pi can be calculated using the function 4 * (1 – 1/3 + 1/5 – 1/7 + …), with more terms giving more precision, write a function to compute Pi to 5 decimal places.
This is a problem that can be solved in 10 lines of C#. But many interviewees have no idea at all. So I have to ask questions like this:
Given that the area of a circle is Pi times the square of the radius, write a function to compute it.
Surprisingly, more than half of the people couldn't write this function in any language! Alas, developers should be able to write code, and now even this has become a controversial opinion...
19. Design patterns do more harm than good.
Software design, especially good software design, is extremely varied and cannot be meaningfully summarized by patterns, especially the few patterns everyone remembers. Moreover, these patterns are too abstract; actually few people truly remember many of them. So design patterns are not very useful. On the other hand, too many people are fascinated by the concept of design patterns and try to use them everywhere—resulting in code that often contains almost no design except some meaningless singletons and abstract factories.
20. Less code is better.
If users can't see your work, that's doing it right. Glory lies elsewhere.
Other popular answers include:
21. Performance really matters.
22. Enterprise applications are ridiculous. Requiring n years of experience is nonsense. Computer science degree programs are pure deception.
23. Unit tests don't help write good code, and most so-called best practices in software engineering are just to prevent bad programmers from doing too much damage.
24. Every programmer should be familiar with modern computer architecture.
25. Write small methods.
26. PHP really sucks!
27. C++ is one of the worst languages ever.
28. Most professional programmers are bad.
29. To become a programmer, you first need to learn typing.
30. The more process rules outside of programming, the worse the code quality.
Senior game programmer James Hague (of the famous blog Prog21) also saw this article and felt these opinions weren't very controversial. He wrote a blog post and proposed views he considered more controversial, many of which pointed to his other previously published articles.
31. Computer science should only be offered as a minor degree.
32. Introducing object-oriented programming to new programmers before they understand how to decompose problems and turn solutions into code is a big mistake.
33. Complex compiler optimizations are almost worthless, even if they produce faster code. They greatly slow down compilation and are likely to introduce difficult-to-handle bugs, making performance problem troubleshooting more difficult.
34. Do not allow people with less than ten years of programming experience to write libraries for others to use. Ignore this rule and you will regret it for life.
35. Whether the code is ugly or not does not matter. Whether it has formatting or not has little to do with whether the code works and is reliable; automated tools can handle the formatting.
36. Pure functional programming is not very useful. But mixing some of it into imperative code works quite well.
37. The established mindset of software engineering will actually hinder you from creating great works.