A few days ago, Yannis Rizos posted 20 controversial programming opinions on the Programmers Community Blog. Judging by the comments on the blog, and on reddit and Hacker News, none of these opinions are considered all that controversial by the programming community at large. The problem stems from the fact that the opinions posted were selected from among the top-voted answers to Jon Skeet’s question What’s your most controversial programming opinion?, originally asked on Stack Overflow on January 2, 2009. People seem to have voted for answers they strongly agreed with, making those top answers some of the least controversial opinions you could gather.
I decided to take a different approach. What follows are some of the opinions that I found near the middle or at the end of the list. I tried to pick only answers where the author made an attempt at supporting their opinion, but as you can see some of these opinions were downvoted more heavily than they were upvoted by the Stack Overflow community. (I'll add that my own "controversial" opinion is that Jon's question is perhaps the best argument we have that these types of opinion polls simply do not work on Stack Overflow.)
1. Two lines of code is too many. (+20/-32) by Jay Bazuzi
If a method has a second line of code, it is a code smell. Refactor.
2. If it's not native, it's not really programming (+5/-15) by Mason Wheeler
By definition, a program is an entity that is run by the computer. It talks directly to the CPU and the OS. Code that does not talk directly to the CPU and the OS, but is instead run by some other program that does talk directly to the CPU and the OS, is not a program; it's a script. Read more
3. The "While" construct should be removed from all programming languages. (+6/-14) by seanyboy
You can easily replicate While using "Repeat" and a boolean flag, and I just don't believe that it's useful to have the two structures. In fact, I think that having both "Repeat...Until" and "While..EndWhile" in a language confuses new programmers. Read more
4. Copy/Pasting is not an antipattern, it fact it helps with not making more bugs (+4/-5) by serg
My rule of thumb - typing only something that cannot be copy/pasted. If creating similar method, class, or file - copy existing one and change what's needed. (I am not talking about duplicating a code that should have been put into a single method). Read more
5. Developing on .NET is not programming. Its just stitching together other people's code. (+7/-5) by Gerard
Having come from a coding background where you were required to know the hardware, and where this is still a vital requirements in my industry, I view high level languages as simply assembling someone else's work. Nothing essentially wrong with this, but is it 'programming'? Read more
6. The use of try/catch exception handling is worse than the use of simple return codes and associated common messaging structures to ferry useful error messages. (+11/-3) by Einstein
Littering code with try/catch blocks is not a solution.
Just passing exceptions up the stack hoping whats above you will do the right thing or generate an informative error is not a solution. Read more
7. Test Constantly (+15/-7) by PJ Davis
You have to write tests, and you have to write them FIRST. Writing tests changes the way you write your code. It makes you think about what you want it to actually do before you just jump in and write something that does everything except what you want it to do. Read more
8. Object Oriented Programming is absolutely the worst thing that's ever happened to the field of software engineering. (+34/-14) by Breton
The primary problem with OOP is the total lack of a rigorous definition that everyone can agree on. This easily leads to implementations that have logical holes in them, or language like Java that adhere to this bizarre religious dogma about what OOP means, while forcing the programmer into doing all these contortions and "design patterns" just to work around the limitations of a particular OOP system. Read more
9. C (or C++) should be the first programming language (+24/-5) by hansen j
The first language should NOT be the easy one, it should be one that sets up the student's mind and prepare it for serious computer science.
C is perfect for that, it forces students to think about memory and all the low level stuff, and at the same time they can learn how to structure their code (it has functions!)
C++ has the added advantage that it really sucks :) thus the students will understand why people had to come up with Java and C#.
10. Classes should fit on the screen. (+22/-7) by Jay Bazuzi
If you have to use the scroll bar to see all of your class, your class is too big.
Code folding and miniature fonts are cheating.
11. Making invisible characters syntactically significant in python was a bad idea (+43/-5) by Paul Wicks
It's distracting, causes lots of subtle bugs for novices and, in my opinion, wasn't really needed. About the only code I've ever seen that didn't voluntarily follow some sort of decent formatting guide was from first-year CS students. And even if code doesn't follow "nice" standards, there are plenty of tools out there to coerce it into a more pleasing shape.
12. Singletons are not evil (+42/-7) by Steve
There is a place for singletons in the real world, and methods to get around them (i.e. monostate pattern) are simply singletons in disguise. For instance, a Logger is a perfect candidate for a singleton. Additionally, so is a message pump. My current app uses distributed computing, and different objects need to be able to send appropriate messages. There should only be one message pump, and everyone should be able to access it. The alternative is passing an object to my message pump everywhere it might be needed and hoping that a new developer doesn't new one up without thinking and wonder why his messages are going nowhere. The uniqueness of the singleton is the most important part, not its availability. The singleton has its place in the world.
Saturday, September 1, 2012
Subscribe to:
Post Comments (Atom)
20 comments:
Exceptions and leave-scope destruction are the most important inventions in programming in the last 20 years. I know lots of Neanderthals I've worked with whose code is littered with bugs because they don't uniformly check return codes (no programmer who uses return codes does).
It's time to evolve guys. Very few programmers use exceptions properly and it's very easy to do so.
I don't get Exception errors because I write my code properly and I test (debug, you fucking noobs, not "test") often.
The only problem I can see with not handling Exceptions because I don't get them is if I run out of memory or some other system error occurs.
Oh, and file IO errors? Non-existent. Just test to see if the file exists, is readable, etc. before you try to get a handle to it. Easy, simple, done.
Seriously kids. Learn to code.
Considering Point 8, Point 9 should read as only C qualifies
Sad that test constantly is controversial. TDD is double entry book keeping for software. Yeah it doesn't guarantee no bugs but it helps and gives confidence in changes.
Classes should fit on one screen - as a rule of thumb absolutely. Smaller cohesive classes are easier to understand.
Try/catch - over use indicates a smell, but throwing an exception is far easier to understand than return codes (which required if/else blocks).
Most of the people commenting on this post are proving the actual post it self.
"a discussion marked especially by the expression of opposing views" - MW's definition of Controversy.
You people should realize that this post isn't saying these opinions are RIGHT, it's saying that a lot of people disagree with them.
They're like the person saying "All humans should be dead." in a room full of people that love life. All the other people will argue against him that it's not true.
So the comments are proof, these opinions (really) are controversial :)
I agree 100 percent with point ten. Singletons have their place when you only want one instance for a business reason, like a logger. The problem is they are overused when people think they only need one instance but there is no valid reason to use the singleton pattern
Here's my "controversial" opinion.
The vast majority of code is encoding procedures that were human practices before they were automated, and businesses push programmers (by gesturing at schedule pressure) to write code with a very narrow, specific focus - not because that's a good way to write software, but in order to avoid the systematic disruption of powerful, general software.
If businesses actually wanted to write software effectively, they would aim for more generality, and expect to spread the benefit across many departments or even across an industry.
TDD, by assisting programmers write with a narrow, specific focus, in the long term shifts power towards incumbent businesses and away from disruptive engineer-led newcomers.
RE: Classes should fit on the screen.
Even if I have a 30" monitor in portrait mode with a super high resolution and a really small font? ;)
Rule number 11 makes the absolute most sense.
Even in C I always put { } into an if statement. Even if I only have one thing in between the braces. It's always best to use more lines to increase readability.
very controversial, nicely done, OP :)
my opinions:
1. wrong
2. pathetic attempt at elitism
3. meh, I don't really care either way
4. wrong
5. true of a lot of development these days
6. wrong
7. agreed
8. wrong
9. sure, if we want to weed out 90% of potential programmers. Good job security for those of us who can handle it, though
10. generally a good idea, but there are places where the business logic you're implementing would be much harder to follow if you arbitrarily broke it into more classes, up, instead of keeping it in-line with the documentation.
11. agreed
12. agreed
I'm sure I sound elitist, but all I'm doing is expressing my opinion in return.
It would seem that controversial opinions in this industry are generally held by partisan groups of elitists.
Saying that .NET isn't programming is a pathetic attempt at feeling superior. I'd say it's a bad first language but it is programming. The idea of .NET isn't to give you low level access to anything, it is to make most routine programming very fast. Back when I worked in .NET I was able to do business apps many times faster than I would have been able to in C. It was also very quick to test and roll out.
Everything is building off of something else, get used to it. Just because .NET exists at a very high level doesn't disqualify it from being a programming language.
I would say that for people like myself who really love the engineering aspect of software, .NET sucks. All the pointy edges are padded and you don't really get to know much about what is going on behind the scenes. I really hope I never have to work with it again, those 18 months were entirely for the money. However, from a business standpoint it is a great language because things can get done quicker.
Seriously? What about network failures, problems from external sub-systems, database issues (constraints, deadlocks), interruptexceptions, disk gets full, etc. etc.
Still fewer use exceptions properly or manage them at all.
Return Codes are extremely useful and produce meaningful, consistent, and testable results. The same cannot be said of exceptions which are generally only useful for the laziest of programmers.
"Developing on .NET is not programming. Its just stitching together other people's code."
This obviously comes from some hardcore C++ or Haskell programmer locked up in a hole. It's obvious that ALL languages have the concept of libraries. Even if you're an elitist, you'd probably have to use some libraries, and reinventing your own is not really an option in most cases.
And stitching is not the hard part; it's getting everything to work together without falling apart.
"Oh, and file IO errors? Non-existent. Just test to see if the file exists, is readable, etc. before you try to get a handle to it. Easy, simple, done."
What the hell?
This is basically the definition of an IO race condition. If someone changes the name of the file between the check and the opening of the file, what happens?
"Seriously kids. Learn to code."
Yep, I'm a kid. Still in school yet I have a better grasp on this than you do.
Two lines of code is too many - really?
If it's not native, it's not really programming - So Java is not programming?
Classes should fit on the screen - again, seriously?
Some of these are not opinions. Probably some words just came out of the mouth for the sake of it...
There is something to be said for teaching future CS majors C as their first high level language, ideally after a quick dose of machine language. An amazing number of people, probably even more now than in the past, have no idea of what is going on inside a computer. They don't know what memory is so they go insane trying to figure out structure allocation, call by reference vs call by value, and so on. They don't realize that the pieces of a program are associated with place in the computer's address space, so they go insane trying to understand anything but the most trivial control structures.
I strongly disagree with the Python one. The problem is with most *other* languages in that curly braces (or some other delimiter) is significant to the compiler/parser, but the space is what is significant in the mind of the programmer.
Indentation in most imperative programming languages is more than an issue of style - it implies to the human reader the block structure of the program and is far more significant (in terms of code readability) than the block delimiters, and yet the block delimiters are what the compiler cares about.
A fun test is to take a block of code from your favorite language and create 2 copies of the file: one without explicit block delimiters and one without indentation (i.e. take turns removing each of the two indicators of block structure in the program). Removing the curly braces has a very slight impact on the code readability, while removing the indentation makes anything but the most trivial files nearly unreadable. Unfortunately in most languages, the version that is valid is the unreadable one, while the readable one is invalid. From a language design perspective, that seems absurd. Languages like Python (it's not just Python of course) correct this.
I'm sure that some people who complain about the significant whitespace have in fact tried it out, but it seems that many who make an issue of it haven't actually tried it for any length of time on any real projects.
The so-called "problems" of significant whitespace are largely theoretical problems that do not actually occur in practice with any regularity. We've used Python at several companies over the past decade, with large teams, and very large projects and significant whitespace has never caused issues. Ever. The skeptical side of me insists that it has caused problems at some point, but I honestly can't remember it *ever* being a problem, and certainly not with the frequency implied by people's comments that the language is flawed because of this design decision.
Python's not a perfect language by any means, but significant whitespace is not one of its problems IMO.
The ability to stitch other's code together is like being the CEO of the programmers. Yes, you can infer this means the code stitcher makes more money than the maker of the code being stitched. When I interview new engineers, start showing them the code base a bit, once in a while, candidates suggest rewriting this and that from scratch. Sometimes you can detect the nature of how they write code. They are perfectionists, wanting to abstract, loosely couple and dependency inject every damn thing they write. This no bueno for my LOB. I am not sure what business they would be for? Furthermore, a developer's desire for elegant code does not equate to code that scales .
maybe not
Post a Comment