Saturday, 18 January 2014

Controversial programming opinions

One of the very first ideas we had for this blog was to convert some
of the wonderful gems of the early era of our site, the undisciplined
period, to blog posts. Questions that were once enthusiastically
received by the community, but no longer fit Programmer’s scope.
The first deleted question I’ve chosen is Jon Skeet’s
“What’s your most controversial programming opinion?” question
(available only to 10K+ users, sorry), a +391 scored question that was
originally asked on Stack Overflow on January 2, 2009. What follows are
twenty of the highest voted answers, in random order…

Programmers who don’t code in their spare time for fun will never become as good as those that do.

I think even the smartest and most talented people will never become
truly good programmers unless they treat it as more than a job. Meaning
that they do little projects on the side, or just mess with lots of
different languages and ideas in their spare time.by rustyshelf

Unit testing won’t help you write good code.

The only reason to have Unit tests is to make sure that code that
already works doesn’t break. Writing tests first, or writing code to the
tests is ridiculous. If you write to the tests before the code, you
won’t even know what the edge cases are. You could have code that passes
the tests but still fails in unforeseen circumstances.
And furthermore, good developers will keep cohesion low, which will make
the addition of new code unlikely to cause problems with existing
stuff.

by Chad Okere

The only “best practice” you should be using all the time is “Use Your Brain”.

Too many people jumping on too many bandwagons and trying to force
methods, patterns, frameworks, etc. onto things that don’t warrant them.
Just because something is new, or because someone respected has an
opinion, doesn’t mean it fits all.

by Steven Robbins

Most comments in code are in fact a pernicious form of code duplication.

We spend most of our time maintaining code written by others (or
ourselves) and poor, incorrect, outdated, misleading comments must be
near the top of the list of most annoying artifacts in code.
I think eventually many people just blank them out, especially those
flowerbox monstrosities.
Much better to concentrate on making the code readable, refactoring as
necessary, and minimising idioms and quirkiness.
On the other hand, many courses teach that comments are very nearly more
important than the code itself, leading to the this next line adds one
to invoiceTotal style of commenting.

“Googling it” is okay!

Yes, I know it offends some people out there that their years of intense
memorization and/or glorious stacks of programming books are starting
to fall by the wayside to a resource that anyone can access within
seconds, but you shouldn’t hold that against people that use it.
Too often I hear googling answers to problems the result of criticism,
and it really is without sense. First of all, it must be conceded that
everyone needs materials to reference. You don’t know everything and you
will need to look things up. Conceding that, does it really matter
where you got the information? Does it matter if you looked it up in a
book, looked it up on Google, or heard it from a talking frog that you
hallucinated? No. A right answer is a right answer.
What is important is that you understand the material, use it as the
means to an end of a successful programming solution, and the
client/your employer is happy with the results.

by PhoenixRedeemer

Not all programmers are created equal.

Quite often managers think that DeveloperA == DeveloperB simply because
they have same level of experience and so on. In actual fact, the
performance of one developer can be 10x or even 100x that of another.
It’s politically risky to talk about it, but sometimes I feel like
pointing out that, even though several team members may appear to be of
equal skill, it’s not always the case. I have even seen cases where lead
developers were ‘beyond hope’ and junior devs did all the actual work –
I made sure they got the credit, though.

by Dmitri Nesteruk

I fail to understand why people think that Java is absolutely the
best “first” programming language to be taught in universities.

For one, I believe that first programming language should be such that
it highlights the need to learn control flow and variables, not objects
and syntax.
For another, I believe that people who have not had experience in
debugging memory leaks in C / C++ cannot fully appreciate what Java
brings to the table.
Also the natural progression should be from “how can I do this” to “how
can I find the library which does that” and not the other way round.

by Learning

If you only know one language, no matter how well you know it, you’re not a great programmer.

There seems to be an attitude that says once you’re really good at C# or
Java or whatever other language you started out learning then that’s
all you need. I don’t believe it- every language I have ever learned has
taught me something new about programming that I have been able to
bring back into my work with all the others. I think that anyone who
restricts themselves to one language will never be as good as they could
be.
It also indicates to me a certain lack of inquistiveness and willingness
to experiment that doesn’t necessarily tally with the qualities I would
expect to find in a really good programmer.

It’s OK to write garbage code once in a while.

Sometimes a quick and dirty piece of garbage code is all that is needed
to fulfill a particular task. Patterns, ORMs, SRP, whatever… Throw up a
console or web application, write some inline SQL (feels good), and
blast out the requirement.

Print statements are a valid way to debug code.

I believe it is perfectly fine to debug your code by littering it with
System.out.println (or whatever print statement works for your
language). Often, this can be quicker than debugging, and you can
compare printed outputs against other runs of the app.
Just make sure to remove the print statements when you go to production
(or better, turn them into logging statements).

Your job is to put yourself out of work.

When you’re writing software for your employer, any software that you
create is to be written in such a way that it can be picked up by any
developer and understood with a minimal amount of effort. It is well
designed, clearly and consistently written, formatted cleanly,
documented where it needs to be, builds daily as expected, checked into
the repository, and appropriately versioned.
If you get hit by a bus, laid off, fired, or walk off the job, your
employer should be able to replace you on a moment’s notice, and the
next guy could step into your role, pick up your code and be up and
running within a week tops. If he or she can’t do that, then you’ve
failed miserably.
Interestingly, I’ve found that having that goal has made me more
valuable to my employers. The more I strive to be disposable, the more
valuable I become to them.

by Mike Hofer

Getters and Setters are highly overused.

I’ve seen millions of people claiming that public fields are evil, so
they make them private and provide getters and setters for all of them. I
believe this is almost identical to making the fields public, maybe a
bit different if you’re using threads (but generally is not the case) or
if your accessors have business/presentation logic (something ‘strange’
at least).
I’m not in favor of public fields, but against making a getter/setter
(or Property) for everyone of them, and then claiming that doing that is
encapsulation or information hiding… ha!

by Pablo Fernandez

SQL is code. Treat it as such.

That is, just like your C#, Java, or other favorite object/procedure
language, develop a formatting style that is readable and maintainable.
I hate when I see sloppy free-formatted SQL code. If you scream when you
see both styles of curly braces on a page, why or why don’t you scream
when you see free formatted SQL or SQL that obscures or obfuscates the
JOIN condition?

by MustStayAnonymous

UML diagrams are highly overrated.

Of course there are useful diagrams e.g. class diagram for the Composite
Pattern, but many UML diagrams have absolutely no value.

by Ludwig Wensauer

Readability is the most important aspect of your code.

Even more so than correctness. If it’s readable, it’s easy to fix. It’s
also easy to optimize, easy to change, easy to understand. And hopefully
other developers can learn something from it too.

XML is highly overrated.

I think too many jump onto the XML bandwagon before using their brains…
XML for web stuff is great, as it’s designed for it. Otherwise I think
some problem definition and design thoughts should preempt any decision
to use it.

by Over Rated

Software development is just a job.

I enjoy software development a lot. I’ve written a blog for the last few
years on the subject. I’ve spent enough time on here to have >5000
reputation points. And I work in a start-up doing typically 60 hour
weeks for much less money than I could get as a contractor because the
team is fantastic and the work is interesting.
But in the grand scheme of things, it is just a job.
It ranks in importance below many things such as family, my girlfriend,
friends, happiness etc., and below other things I’d rather be doing if I
had an unlimited supply of cash such as riding motorbikes, sailing
yachts, or snowboarding.
I think sometimes a lot of developers forget that developing is just
something that allows us to have the more important things in life (and
to have them by doing something we enjoy) rather than being the end goal
in itself.

by Greg Beech

If you’re a developer, you should be able to write code.

I did quite a bit of interviewing last year, and for my part of the
interview I was supposed to test the way people thought, and how they
implemented simple-to-moderate algorithms on a white board. I’d
initially started out with questions like:

Given that Pi can be estimated using the function 4 * (1 –
1/3 + 1/5 – 1/7 + …) with more terms giving greater accuracy, write a
function that calculates Pi to an accuracy of 5 decimal places.

It’s a problem that should make you think, but shouldn’t be out of reach
to a seasoned developer (it can be answered in about 10 lines of C#).
However, many of our (supposedly pre-screened by the agency) candidates
couldn’t even begin to answer it, or even explain how they might go
about answering it. So after a while I started asking simpler questions
like:

Given the area of a circle is given by Pi times the radius squared, write a function to calculate the area of a circle.

Amazingly, more than half the candidates couldn’t write this function in
any language (I can read most popular languages so I let them use any
language of their choice, including pseudo-code). We had “C# developers”
who could not write this function in C#.
I was surprised by this. I had always thought that developers should be
able to write code. It seems that, nowadays, this is a controversial
opinion. Certainly it is amongst interview candidates!

by Greg Beech

Design patterns are hurting good design more than they’re helping it.

Software design, especially good software design is far too varied to be
meaningfully captured in patterns, especially in the small number of
patterns people can actually remember – and they’re far too abstract for
people to really remember more than a handful. So they’re not helping
much.
And on the other hand, far too many people become enamoured with the
concept and try to apply patterns everywhere – usually, in the resulting
code you can’t find the actual design between all the (completely
meaningless) Singletons and Abstract Factories.

by Michael Borgwardt

Less code is better than more!

If the users say “that’s it?”, and your work remains invisible, it’s done right. Glory can be found elsewhere.

Hopefully More Controversial Programming Opinions

I read 20 Controversial Programming Opinions,
and I found myself nodding "yes, yes get to the good stuff." And then,
after "less code is better than more," it was over. It was like reading a
list of controversial health tips that included "eat your veggies" and
"don't be sedentary." In an effort to restore a bit of spark to the once
revolutionary software development world, I present some opinions that
are hopefully more legitimately controversial.

Computer science should only be offered as a minor. You can
major in biology, minor in computer science. Major in art, minor in
computer science. But you can't get a degree in CS.

You shouldn't be allowed to write a library for use by other
people until you have ten years of programming under your belt. If you
think you know better and ignore this rule, then one day you will come
to realize the mental suffering that you have inflicted upon others, and
you will have to live with that knowledge for the rest of your life.

Superficially ugly code is irrelevant.
Pretty formatting--or lack thereof--has no bearing on whether the code
works and is reliable, and that kind of mechanical fiddling is better
left to an automated tool.

Purely functional programming doesn't work, but if you mix in a small amount of imperative code then it does.

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

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

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

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.

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.