Lots of these opinions are "controversial" because they are a load of hogwash.

If a method has a second line of code, it is a code smell. Refactor.

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.

"4. Copy/Pasting is not an antipattern, it fact it helps with not making more bugs"

I think what he/she means is that side effects are bad.

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.

2. If it's not native, it's not really programming

The "While" construct should be removed from all programming languages

Developing on .NET is not programming. Its just stitching together other people's code.

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.

Object Oriented Programming is absolutely the worst thing that's ever happened to the field of software engineering.

Making invisible characters syntactically significant in python was a bad idea

Classes should fit on the screen.

Oh and in C that would be the do..while cycle.

What does that even mean?

One common mistake new programmers make with While is they assume that the code will break as soon as the tested condition flags false.

Yeah, the guy is obviously clueless or trolling to be controversial.

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#.

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.

Programs must be written for people to read, and only incidentally for machines to execute.

[...] when you have an setter on an object you turned it back into a data structure.

Personally, my (biggest) issue with C++ is that it's simply too large of a language. If you get 10 people who say they know C++ chances are good that the only overlap is going to be the subset of C++ that is C.

C++ also reinvents a bunch of things from C (such as I/O) and it's debatable whether it actually improved them.

tl;dr. C++'s flexibility is both its strength and its weakness. It allows you to do all sorts of crazy things, but at the end of the day they're still crazy.

"2. If it's not native, it's not really programming

Or really anything that doesn't turn your execution order into spaghetti.

The author was lamenting the simple fact that OO is too vague.

That's the whole reason you people use it.

try/catch/finally does it by default

Except the STL is almost entirely duplicate functionality. list and map are the only new containers. Everything else is either a duplicate or a minor change away from being a duplicate.

Vectors don't really make life easier. And RAII is only useful if you're doing OO.

The C I/O functions work at least as well as C++'s, even on objects.

Honestly, I think Qt is crazy, but most GUI programming is.

"try/catch/finally does it by default

Nobody said those opinions had to be valid; only that they had to be controversial.

That doesn't make any sense either. If you don't need to make sense just for the sake of being controversial, then how about these?

1. Everyone should always write code using two toes of their choice but only from their left foot.
2. No function should ever be more than 82 lines of code, except on a Tuesday when they should be no more than 81 and 83 lines long.
3. Every single programmer should learn COBOL. No exceptions.
4. Always name your variables as anagrams of the word "hexaphene"
5. Never compile your code after dark.
6. The letter 'y' should be banned from use in Java.

Yes, but the people who are really proficient with C++ will use the STL, which has no overlap with C, because C simply does not have the facility.

I haven't had to do a crazy thing in C++ at all. Have a look at Qt. Aside from the MOC (which translates to standard C++ anyway), there is nothing crazy with Qt.

"What does that even mean?

Problem with C++ is that it's so wide that finding a group of people that think the same way about C++ is virtually impossible.

Notice he was also the guy that came up with "If you have to use the scroll bar to see all of your class, your class is too big."

I fail to see why this is a problem. The multi-style nature of C++ is better than trying to cram every problem into an OO or functional or message passing style.

All those containers are duplicates of other containers in the STL. Also, Boost is a nightmare, not a benefit.

If you can't manage an array, then you have no right to be talking about "complicated things." Arrays are not difficult things to work with. Push, pop, insert, and delete are all straight forward functions (that C should have defined, but I digress.) Keeping track of the length is also not difficult (and can be managed by the push/pop/insert/delete functions.)

"I fail to see why this is a problem. The multi-style nature of C++ is better than trying to cram every problem into an OO or functional or message passing style.

And no, there are not two ways of doing things in C++, there are thousands. In short - too many to be good for assembling and maintaining a team.

"Make sure you aren't putting any unnecessary shit in there."

I see a lot of massive classes where some things could have been broken down better via inheritance.

And that's the fault of the language is it?

"And that's the fault of the language is it?

The only UML diagram I think any one uses regularly is the UML class diagram. That is where the confusion lies.

I haven't really used UML except for class diagrams since university.

We were told not to use Flow Diagrams at University, but they are pretty good for non-developers to see a high level flow of logic and developers can just follow it through in a debugger if need be (Our codebase is very bad).

Sets, queues, and stacks are all lists. They have slight restrictions, but that's the very definition of "minimal change."

Boost is quite commonly regarded as a major example of terrible software (by the non-C++ using community.)

It is about difficulty, because I've already enumerated how to use arrays safely. Pointing out that lots of developers have bad habits is simply a red herring.

Strangely, I think UML class diagrams are perhaps the most useless UML diagram. They're pain to make, class design changes all the time, and thus they're a pain to update.

Regarding flow diagrams, I find UML sequence diagrams to be a better replacement.

For me, the trick with UML and any diagramming language is not to go into any detail. Anything more than a brief outline is even more ridiculous to maintain and keep accurate than code itself.