The most controversial programming ideas

Address: http://www.myexception.cn/other/1391149.html

The reason why stackoverflow is successful on a well-known Q & A website is that reasonable rules and strict execution are important. Therefore, it is often necessary to delete posts. However, sometimes the execution is too strict, and the deleted Q & A may be amazing from time to time. This is not the case. What their blog post in August 29 "20 most controversial programming views" says is such a deleted post. This article immediately aroused heated discussion on major technical news sites such as Reddit and Hacker News.

 

 

In fact, in 2010, cool shell once introduced ten of the articles, but his views were not translated. The original question "What is your most controversial programming point of view ?" (We can see the archive here), proposed by Jon skeet in January 2009. This person is not an unknown pawn. C # is a famous character in the community. He has been a Microsoft MVP for many years and has written a book titled deep understanding of C # (English Version C # In depth) the book is a rare masterpiece in the C # field (Lao Zhao said C # He only recommends two books, this book and CLR via C #), now Google is an engineer in the UK company (I really don't know what he is doing there ). So what are the hot answers to this question? The order is random. 1. programmers who do not program for fun in their spare time can never match those who are happy with programming.I think that even the smartest and most talented people, if they only work on programming, will never become really good programmers. People who are happy with programming will also engage in small projects in their spare time, or develop different programming languages and ideas. 2. Unit testing does not help you write good code.The only reason for writing unit tests is to ensure that the code that can already work will not go wrong. Writing a test first or writing a code based on a test is ridiculous. If you write a test before the code, you do not know what the boundary is. Although the Code can pass the test, there will still be problems in situations that are not foreseen. In addition, good developers will try to reduce cohesion, and new Code cannot cause existing problems. 3. The only best practice that can be put in full swing is "thinking with your mind ".Too many people like to pursue many fashionable technologies and try to apply various methods, models, and frameworks to unsuitable places. The ideas of new technologies and celebrities are also applicable to actual situations. 4. Comments in most codes are actually a vicious manifestation of code duplication.We spend most of our time maintaining code written by others (or ourselves), and bad, wrong, outdated, and misleading comments must be one of the most tangled items in the code. Many will eventually kill them. We should focus on improving the readability of the Code, refactoring when necessary, and reducing the use of idioms and tricks. In addition, many textbooks are still promoting comments that are even more important than the code. As a result, a large number of comments are produced. 5. There is nothing wrong with relying on Google.These comments will certainly make those who have learned the best five cars angry. But does anyone need to check the information? The correct answer is the correct answer. Which of the following is the secret or private message from Google? What is important is to be able to really understand and give successful programming solutions to satisfy the customer and the boss. 6 . Programmers are not born equal.Managers often think that programmer A = programmer B because they have almost years of experience. In fact, the efficiency of a developer can be 10 or even times that of another developer. 7. I really cannot understand why Java is the first language most suitable for university teaching.First, I believe that the first programming language should focus on learning control flows and variables, rather than objects and syntax. Secondly, I don't think anyone who has no experience debugging C/C ++ memory leaks can fully understand the original intention of Java. In addition, the natural development process should be from "how do I do this" to "How do I find the database that can do this", rather than turning it over. 8. If you only speak one language, no matter how proficient you are, you are still not a good programmer.Some people think that it is enough to be proficient in C #, Java, or other first language you have learned. I agree. Every new language I learned has taught a lot of new programming knowledge that can be used in turn at work. No one is confined to one language and cannot make full use of their potential. Lack of curiosity and willingness to explore is not in line with the characteristics of excellent programmers. 9. Occasionally writing spam code is fine.Sometimes some specific tasks can be completed quickly with dirty code. Model, Orm, and SRP (single responsibility principle. 10. Print statements are effective debugging methods.I think it is good to debug the code using output statements such as system. Out. println. This is often faster than the formal debugging, and the output results of different operations can be compared. However, before entering the production environment, you must delete these statements or put them into the log statements. 11. Your job is to pick yourself out.The software you write should allow any other developer to understand and take over the software in a little time. The software should be elegantly designed, the code should be clear and consistent, the format should be clean, the documents should be appropriate, the daily construction should be made, and appropriate version management should be available. If you are hit by a car, fired, or resigned, the company should soon be able to replace you with someone. If you can't, it's a tragedy. Interestingly, the more you do this, the more valuable you are to the company. Someone commented below the original post: if you cannot be replaced, you will not be promoted. 12. getter and setter are greatly abused.Thousands of people say that public fields are evil and should be set to private to provide getter and setter. I think there is no difference, unless the program is multi-threaded, or there is business or presentation logic in the access method (this is strange enough ). I am not in favor of using public fields. I am not only opposed to using an access method or an attribute package. It is called encapsulation and information hiding. 13. SQL is also the code. Please wait for it.SQL and C #, Java, or other objects and process languages are no different. Pay attention to the code format, readability, and maintainability. 14. The UML diagram is overestimated.Some graphs are useful, for example, class diagrams in the composite mode. However, many UML diagrams have no value. Csdn Editor note: I remember when Robert Martin talked about UML in Agile Software Development (C #), he basically talked about a diagram and said, it seems useless, I have never used it ...... There is also a related answer to the same question: code = design. Advanced language code is more effective than UML diagrams and documents. 15. Readability is the most important aspect of the Code.Is more important than correctness. Readable code can also be easily corrected, which is easy to optimize, modify, and understand. Other developers can also benefit from this. 16. XML is greatly overestimated.Many people jump onto the XML black ship without thinking about it. XML is good for Web applications because it is originally intended for this purpose. In addition, you should try not to use XML for problem definitions and design ideas. 17. Software development is just a job.I love software development. I am now working in a startup company, working 60 hours a week, and my salary is not high, just because my team is great and my work is very interesting. However, it is still a job to stand up. It is not as important as family, my girlfriend, other friends, and happiness. If I have enough money, I would rather go on a motorcycle, yacht, or board skiing. Many developers forget that writing a program is not the ultimate goal. It just provides us with conditions to happily do the most important thing in our lives. Csdn Editor's note: This article and article 1st seem to be a little opposite. 18. Developers should be able to write code.I did a lot of interviews last year. I will mainly test people's ideas on how to implement simple algorithms on the whiteboard. I often start with this problem: Known pi can use function 4*(1-1/3 + 1/5-1/7 + ...) Calculation: the more items, the more accurate it is. Write a function to calculate the PI of the 5 digits after the decimal point.This is a problem that can be solved with 10 lines of C. However, many interviewers have no idea. So I had to ask the following question: The area of the known circle is the square of the PI multiplied by the radius, and a function is written for calculation.More than half of users cannot complete this function in any language! Alas, developers should be able to write code. Now even this is a controversial point of view ...... 19. The design pattern has more disadvantages than advantages.Software design, especially good software design, is ever-changing and cannot be summed up with patterns in a meaningful manner, especially the several patterns that everyone remembers, and these patterns are too abstract, in fact, few people really remember too much. Therefore, the design model is useless. On the other hand, there are too many people fascinated by the concept of design patterns and try to use them everywhere-the result code is often in addition to some meaningless singleton and abstract factory, almost no design can be found. 20. The code is less beneficial.If the user does not see your work, it is the right thing to do. Glory elsewhere. Other popular answers include: 21. performance is really important.  22. Enterprise applications are funny. It takes N years of experience. Computer science degree courses are simple and simple.  23. Unit Testing does not help to write good code. Most of the so-called best practices of software engineering are designed to prevent too many damages by bad programmers.  24. Every programmer should be familiar with the architecture of modern computers.  25. Write a small method.  26. php is really bad!  27. c ++ is one of the worst languages in history.  28. Most professional programmers are very bad.  29. To become a programmer, you must learn to type.  30. The more rules there are, the worse the code quality.Senior game programmer James hgger (also known as prog21) also saw this article and thought these ideas were not too controversial. He wrote a blog and put forward his own opinion that is more controversial. many of his views point to other articles he published earlier: 31. The computer science major should only serve as a secondary degree.  32. It is a big mistake for new programmers to introduce them to object-oriented systems before they understand decomposition issues and turn solutions into code.  33. Complex Compiler optimization has almost no value, even if you can get faster code. They greatly reduce the compilation speed and are likely to generate bugs that are hard to handle, making it more difficult to handle performance problems.  34. Users without ten years of programming experience are not allowed to write libraries for others' use. Ignore this article and regret it for life.  35. Whether the code is ugly or not does not matter. There is no relationship between the format and whether the code is working and reliable. You can use automated tools to organize the format.  36. Pure Functional programming is useless. However, it is good to use other commands in imperative code.  37. The established thinking of software engineering hinders you from making great works.