Strictness in programming methods among Stack Overflow users [closed]

The point is not to always use the "best" and "most general" solution in existence for your problem per se, and only that (for any specific definition of "best" and "portable"). However, a good programmer should be aware of the limitations and consequences of different approaches. Without this, you are prone to get into deep trouble down the line, especially in a language like C++ which is not at all forgiving to such errors.

Note also that projects tend to outlive and outgrow their expected lifetime and range of application. More experienced programmers have already seen (and possibly have been burnt by) cases when an innocent request to port a working app to a new platform caused untold grief to developers, when zillions of subtle portability issues were discovered all of a sudden in code which so far was running perfectly on its original platform(s). (And such problems may every now and then surface even without migration, on platforms where the code seemed to be running fine for years.)

So experienced programmers tend to strive to use the most portable, standard, mainstream idioms, because they reason that it is usually much less effort to do so in advance, than trying to fix all those portability issues afterwards.

I believe the downvotes might be a result of being imprecise / uninformative from your part. Maybe if you post answers which you know are limited in some way, you should document those limitations too (like "this simple search algorithm is fine for a set of a few dozen elements, but for bigger sets it is better to use algorithm X"). Any good solution should include notes on its limits and caveats too - if you add these, you may even get upvotes instead of downvotes.

Update

Portability is one specific issue; others are simplicity, readability and safety. Using hand written code instead of the equivalent standard library call almost always means that you are achieving the result with more code, which is more error-prone and also its performance is potentially worse. More code is harder to read and understand for your successors, thus its maintenance is costlier. (There is that 1% exception when someone writes a specific implementation of an algorithm for a good reason, and the solution is tailored for a specific purpose, well thought out, researched, tested and documented - those cases are completely OK, such as the ones discussed in Programming Pearls. But you have to have a good reason and work really hard to fit into that 1%...)

Macros are a remnant from C, kept for backward compatibility, and - as others have noted - in 99% of the cases there is a better, more "C++" way to solve problems, e.g. templates. It is always advisable to prefer the safer, higher level, more common idioms which are better supported by the compiler too, if you can. Especially if you don't know inside out the 101 ways in which you can shoot yourself in the foot with careless use of a macro :-)

(Disclaimer: I know a few, but far from all. I am definitely not a C/C++ guru.)

These are not rules, but opinions of people.

Individuals read the question and the different answers (including yours) and decide whether to vote them up or down. They do this based on their own experience and knowledge - instead of thinking of them as restrictive, think of them as educational.

People see an answer and if they think it is not the best way to resolve the issue that has been asked about (or believe it is actively harmful), they downvote.

I suggest that you add more information to your answers, especially if you know that they will be controversial enough for most people - explain why you believe it is a better solution than the alternatives (showing you understand the alternatives) and why the downsides are acceptable (showing you understand the downsides).

I think that what you describe is the visible effect of "there is the better way to do this" approach, which is mostly a good thing. Let me elaborate.

One issue is that since we 're talking about programming, for each problem there will probably be quite a number of ways to achieve the desired result which will only have trivial differences if you only look at what instructions are executed (the for loop approach that you mention). Some of these approaches will be judged "better" in the sense that they better fit the style of the language (in other words, they are idiomatic). For example, in C++ you could write a for loop to count occurences of 'x' in an std::string, but it's "better" to use count_if instead.

Another issue is that while many approaches might be equivalent for the specific problem at hand, some of them might be more generalized than others. Since a major virtue (or fault) of code is its degree of generality, "specialized" code will generally be frowned upon. The definition of generality here is itself a bit loose: general might mean "will work with an extended set of inputs" or "will work across more platforms" or something else in these lines.

In the end, I believe that many of the knowledgeable people on SO achieved their level of knowledge by always striving to find a "strictly better" approach. After finding one, it's hard to argue for something "inferior". This should explain why some approaches will be heavily voted down or otherwise shunned. In those cases where an approach which is generally undesirable has actual advantages due to the specifics of the situation you will find that people do judge it on its technical merit and do not vote it into oblivion.

As for the "what about Linux kernel code" question, there's also another dynamic in effect here: the Linux kernel is a very large code base that has to be maintained and expanded, while questions on SO tackle smallish issues and do not have the burden of legacy code, backwards compatibility, possibly regrettable design decisions that were made 10 years ago, etc. So while we won't frown on the current Linux kernel code, we might do so if someone started writing it from scratch and approached it in the same manner today.

Disclosure: I 've never looked at Linux kernel code. It's only intended to give a name to an abstract example.

I obviously can't speak on behalf of other users, nor do I know the exact context of which you speak of. Nevertheless, I will attempt to address your points. Since I am way more familiar with C++ than C, I will speak from the perspective of a C++ programmer. Note that C++ is a totally different language from C.

I've been a member of stackoverflow for a couple of weeks now and have answered questions and read others answers, mostly in C/C++. True, I have learned about some things. For example, undefined behavior which in the past, knowing what's going on from inside the CPU to compiler code generation, all those "seemed" defined and worked as I expected them to. I understand now how conforming to rules such as not evoking undefined behavior are good for you, even though you know in your PC, in your compiler it works without a flaw.

That's great, I'm glad you're learning something from Stack Overflow. No seriously, I'm not being sarcastic; learning and spreading good information among members of the community is one of the goals of the site.

However, at times I got negative points for answers involving using macros or certain codes that makes me wonder why among people here, there are such very strict rules. For example, almost any time you talk about macros, people say use functions instead. I understand that functions are better in many ways, but there are many places macros are more fit. Are macros so frowned upon here? Another example is, if for any reason you write a simple for loop to find a character, you get a lot of comments telling you to use prewritten functions instead or you get negative points for suggesting the loops. I understand the functions in standard library have all kinds of error checking in them and probably are most efficient in general, but is it such a crime to write a simple loop for your own specific case?

There aren't any "rules"; they're more like guidelines than anything else. I agree that there are situations where macros are justifiable. In fact, one of my answers involves a macro at the end and it has 49 upvotes at this time of writing. Boost.Foreach is a big macro, and people don't mind suggesting it as a solution. But there's often a better solution than macros in 99% of the cases, and it's just that some people disagree with your assessment that a macro is necessary in a specific situation. Also, writing a macro that is robust is very hard.

Personally, I wouldn't downvote you for using a simple for loop, as long as it's correct. There is nothing wrong with "do it yourself" code per se. But unless it's for exposition, I may put in a comment that there is in fact a faster/better/more readable way to do it. Especially if the standard library provides a ready-made tool you can use.

What I'm asking is more general than these mere examples. It seems to me that among the users of stackoverflow, there is "defined" (if not written) standard of coding in C/C++ and that's the only way they accept it. I'm not saying it's bad. I'm not saying that at all. I learned a lot myself about things that made my code not portable. However, almost all of those things turned out to be too much restriction. Things such as if you do like this, your code won't work in computers that don't encode characters in ASCII. Do you think people will always want their code to run on all possible computers? Isn't that a bit too much? A simpler, faster method that you know works on computers you know your program would run on, seems to me a better solution than a completely portable one.

I can't speak for those people who say those things, but we point them out because the OP may not be aware of the caveats. If I post code, I will always try my best to point out any and all underlying assumptions I have when I wrote that code and that the OP should be aware of them. For example, if I write a string routine with the assumption that a wchar_t represents a UTF-16 code unit, I will point that out because I can't possibly know every single detail of the OP's problem context. Especially since a wchar_t may not in fact represent a UTF-16 code unit on the OP's target platform!

There are great codes out there that seems to me if they were judged here, they would get the worst results. Codes such as the Linux Kernel, implementation of STL that comes with g++, Mesa3D's implementation of OpenGL and so on. Look at these codes and your eyes are flooded with macros and bitwise operations. Do you condemn the programmers of the Linux Kernel too? Would you rather have your OpenGL library drop framerates by 10% but possibly run on a 16bit microprocessor too?

You do realize that such code is written by more than one person, right? Believe it or not, some people write better code than others (for some definition of "better"). Also, they may not represent the best practice due to pragmatic reasons. For example, the Qt framework code doesn't even come close to representing modern C++ code (no exception safety, for example) but completely changing it would be too costly. The Linux kernel was developed before modern C++ came to be, so of course it is very C-ish (and let's not forget Linus Torvald's strong opinion on C++). The STL implementation on g++ needs to be able to support many different platforms, so of course it will have macros to change out code for specific platforms.

In other words, those examples that you speak of usually have a reason why it's designed like that. However, the OP may not be in the same situation as those examples.

So, is what occurred to me true? Are people in stackoverflow so strict on judging others' codes? Or have I just been unlucky enough to stumble upon a minor few?

We are strict in the sense that we strive to provide the best, most complete answers possible. This is important as Stack Overflow is one of the most visited programming resource sites on the World Wide Web nowadays, so there's a feeling of moral responsibility with regards to the precision of the posts on Stack Overflow. To this end, our suggestions and criticisms are relevant only to the information in your answers; they are not meant to be attacks on you as a person.

The one thing that kept making me stricter for the last two decades was bad experience. Once using a tool hurt you, you tend to be much stricter in dealing with the tool, and pay more heed to what others say about being careful.

There's well-explained reasons macros are frowned upon in C++ (as well as the admission that there are - a few - things that can only be done by macros) and there are very good reasons to use the standard library's algorithms, all of which have been explained quite well at many places on the web, rather than making your own, and all of these rules have been learned by someone being bitten. Be glad they shared that experience with you, it allows you to get away without being bitten, too.
And my own bad experience says that any piece of code might be required to be ported to some esoteric platform at some point in time later, no matter how much the managers guaranteed that this would never ever happen.

As the result of this experience (my own and that of others) is that I strive to write my code as standard-conforming as possible, use all the building blocks provided by the standard library I can think of (rather than writing my own), and be as strict as I can about my code.
Believe me, if you ignore these, it will hurt, sooner or later.

On the other hand, I can see good reason to ask why those rules are seen as so important by those who correct you. Doing that can lead to very good questions and answers that help many other users.

P.S.: You might want to learn to not to confuse C and C++ when it comes down to questions of programming style. This is where they differ most, after all.

A lot of the techniques you want to use are low-level, and a lot of the code you list is also low-level. It has to be fast and it has to be efficient, and that means the code needs to use macros, for loops, etc.

Many of the answers for C++ code I've seen assume you are writing code for desktop applications. In those cases, you probably can avoid using pointers and use stack-allocated objects or smart pointers. You can use the STL and you can use iterators instead of plain old for loops.

Most of my C++ work has been for the Nintendo DS, which is basically an embedded system with a 16K stack and 4MB of RAM. I look at the C++ answers here, which all promote a modern approach to C++ work, and think to myself, "You've just blown the entire stack on one object allocation and crashed the hardware. There's no way this coding style will work for me."

First, C and C++ are two different languages and some rules are accepted in one and not the other for basic usage. C++ Programmers know that C++ was and is still badly taught as a "super C" and a lot of code base in companies is a bad mix of C and C++ and they frown on people that continue to perpetuate these tendancies.

Then, I think people for educational purpose maybe prefer to show a general approach rather then specific ones ( like using a macro where a function could do ).

Library code is in my opinion very specific and not at all educational.

On Macros

The general consensus among C++ programmers is that macros should be avoided unless a damn good reason is presented to do otherwise. They don't play well with the type system, they don't play well with other features, and they don't play well with most debuggers. Therefore, there are some programmers who will downvote an answer that suggests a macro solution with a solution that doesn't use macros is available.

If that's a programming style you like, if you feel comfortable with macros, that's up to you. But StackOverflow is a democracy, and as such, people will hold you accountable for your views.

That being said, it only takes one person to downvote your question/answer. Hundreds of people will see your questions/answers. If one of them sees something they find distasteful enough to downvote it, then it will be downvoted. So just because you were downvoted for macro usage doesn't mean that there is in fact a general consensus against macros.

There generally is, of course. But a single downvote doesn't mean that.

On Shortsightedness

Do you think people will always want their code to run on all possible computers? Isn't that a bit too much?

I imagine that quite a few C/C++ programmers have been bitten by someone who wrote some code under some assumptions that later proved not to be valid. Someone who was paying attention only to the here and now.

ASCII is one of those things. ASCII has been the de-facto standard for strings for ages. It's simple and clean to use. The problem is that Internationalization is the order of the day in most programming circles. So when a C/C++ programmer sees someone suggesting code that won't work when used with Unicode encoded strings, what they are seeing is themselves having to later fix that code when someone suddenly decides that they need to use Unicode strings.

Basically, when they see ASCII-only code, they start getting flashbacks of them having to ransack some codebase to make it work in a post-ASCII world.

Shortsightedness is something that many programmers have had to deal with. And they will naturally become rather judgmental of programmers who don't take the long view. Because they themselves have had experience dealing with such systems.

Sometimes, having a narrow focus makes sense. The Zero/One/Infinity rule is based on that, with One being something that has a defensible restriction. However, too often, programmers think their focus is narrow, then their bosses come in and broaden the scope. Now they have to take a sledgehammer to that narrow code to broaden it.

In Conclusion

Are programmers judgmental about style? Some are. Some will downvote based on poor style. Personally, I downvote anything that uses sprintf (seriously people, snprintf already!) Every programmer has their pet peeves. For some, it's macro overuse. For others, it's people giving no thought to Internationalization. But everyone has their stylistic pain points.

The best thing you can do is try to understand where those stylistic issues come from, and extract whatever wisdom may lie behind that thinking.

About your own code vs. prewritten functions:

• suggesting your own code may indicate that you are not aware of the library function. In the case of fetching a character this may be minor but in general, your productivity is increased if you take the habit of using off-the-shelf components.

• using your own code means introducing your own bugs and writing your own tests. Prewritten functions have the huge advantage of having been tested in many more real-life situations than you would have time to test your own code.

Many strict coding practices that may appear rude when downvoted have their rationale. Find them and you will improve.

This is a great thing for learners that coding standards are so high on Stackoverflow.

On SO code is judged differently. When you put some code on SO, it get's high visibility. Especially beginners are exposed to it. This is why people are far more strict with it, that with any other (actual) code they review.

The point is, somebody who doesn't know all the corner cases you ignored might merely copy your code and then wind up with some bugs, that are extremely hard to trace back to that piece of code, if you're unexperienced. And boom, some youngster has just wasted a few days of his life on code, that's not even his.

Instead, your peers understandably promote standardized and robust approaches. Nobody should go hacking about, without knowing how to do it by the book first.

Personally I do sometimes sketch out ideas in substandard code on SO, but in that case I always make readers aware of flaws in the code.

Do you think people will always want their code to run on all possible computers? Isn't that a bit too much?

I spent the bulk of the '90s writing C code that had to run on at least two platforms (Windows and *nix, primarily, with classic MacOS thrown in occasionally) concurrently; at one point I was supporting 5 different platforms. I've had to port code between minis (VAXen, HP 3000, Encore) and *nix more than once.

I've been bitten by type size issues, endianness issues, representation issues, etc., on multiple occasions. So yeah, I tend to think in terms of "will this code work everywhere" when I'm initially writing it. Occasionally I will have to make platform-specific assumptions, but I tend to hide those behind a generic interface. I keep the bulk of my application code as generic as possible.

I've been a member of Stack Overflow for a couple of weeks now and have answered questions and read others answers, mostly in C/C++.

Firstly, C++ and C are two incredibly different languages. If you're lumping them together like this, then you almost certainly don't have a clue about C++. And secondly, on Stack Overflow, as far as I know, the C++ community is very different to the C community.

More importantly, you just seem to miss the point. Stack Overflow is for everyone. It's for every implementation- unless the asker explicitly restricts it. It's for learning. You might know that a for loop is fine in a really simple case- but did the asker? Probably not, if that's what you had to answer with.

However, almost all of those things turned out to be too much restriction. Things such as "if you do like this, your code won't work in computers that don't encode characters in ASCII". Do you think people will always want their code to run on all possible computers? Isn't that a bit too much? A simpler, faster method that you know works on computers you know your program would run on, seems to me a better solution than a completely portable one.

You don't know what platform the asker's code runs on. Unless he specifies that he only needs ASCII, in which case that's fine. Apart from that, you have to take into account the fact that he might be running in Japan. It's not acceptable to write code for the general case when your code doesn't work in the general case.

There are great codes out there that seems to me if they were judged here, they would get the worst results. Codes such as the Linux Kernel, implementation of STL that comes with g++, Mesa3D's implementation of OpenGL and so on. Look at these codes and your eyes are flooded with macros and bitwise operations. Do you condemn the programmers of the Linux Kernel too? Would you rather have your OpenGL library drop framerates by 10% but possibly run on a 16bit microprocessor too?

Those are special cases. The Linux Kernel is written in C and therefore almost by definition sucks tremendously from the perspective of a person who can use C++, but running in kernel mode is a special case (doesn't excuse too many horrendous flaws) and Stack Overflow is the general case. Being the implementation of a compiler & library is also a special case. However, you're just being blind. Those codes aren't necessarily great codes at all. I can tell you now that the G++ implementation doesn't use SFINAE on the std::function constructor and causes ambiguous overloads when there's no need to, for example.

Oh, and nobody said that bitwise operations are bad. They're not. Macros are, though.

Just to summarize: You just don't know where the line is between "C", "C++", and when it's OK to use implementation-defined behaviour. For example, in implementations.

You need to learn to appreciate being downvoted -- someone's trying to teach you something. My first SO answers were sometimes downvoted harshly for seemingly trivial reasons, despite working and not being wrong in any objective sense. E.g., I read through a file using a motif like:

f = open('some_file.txt','r')
for line in f.readlines():
    do_something(line)

rather than

with open('some_file.txt', 'r') as f:
    for line in f:
        do_something(line)

I now look at the top code and know its significantly worse than the bottom code, posting to SO and getting downvoted taught me something and improved my code going forward. The original code is less pythonic (it only works if f has a readlines method, while the second works for any iterable and is equivalent in the file case), slower (for line in f is faster than for line in f.readlines()), doesn't close the file after opening it (which the with block ensures), etc.

Getting downvoted is not a bad thing; yes you lose -2 rep, but remember the person who downvoted you sacrificed -1 to teach you (and the community) something. Try to learn from it. (Also every time you get a downvote and an upvote, it still amounts to +8 rep). Even if the downvoted code works, it may be ugly and likely to lead to problems down the line.

Just a few short things...

Programmers are not good at evaluating if code is good or bad unless bad code has bitten them.

No matter how long you program you will continue to be bitten--to learn new patterns to avoid.

As to why people on SO mention it, it's because this is considered a reference site--this is the one place where practices should be absolutely held to the best practices we know of so that when others use it as a reference they actually get good code and not a simple hack.

One thing you might want to keep in mind is that the OP is not the sole audience for an answer. Perhaps the OP is aware of all the possible concerns, all the potential limitations of all answers (though more likely they aren't). But that's not the end of the story. We expect that a lot of other people may see the question and answers much later, probably via Google, and so a really good answer has to be careful to be correct for everyone in all situations, not just you.

It may well be that for your purposes, your more laid-back style is fine. Maybe you'll never run into the potential problems with macros; maybe you'll never run into encoding and portability issues; maybe your quick-and-dirty solution is good enough. But these answers are posted for all to see, now and a year from now and perhaps a decade from now. Someone else who's coding in a completely different environment might happen across them, and for them, all of those caveats might be a huge deal. Better to be safe than sorry, and better to write a perfect answer than a presently adequate one.

And of course, as everyone's noted, the downvoting and comments are just trying to guide you toward what the community regards as higher quality answers. It doesn't mean your answers won't work for you; it just means you can do a little better, and we want to tell you how.

Short version: Yes, I think that SO users can be very strict, and it's a good thing.

I can tell you why I sometimes downvote answers that work (it's clear why we downvote answers that don't work). In any language (I'm a SQL girl), there are multiple ways to do many things and some are suboptimal. By suboptimal I mean, they may often cause a maintainibility problem or a know performance problem or a security problem or some other type of issue or they are just not the right tool for the task described. I do not want the OP to think the suboptimal solution is the one to choose because he found it easiest to understand or because it was posted first. We don't want people to learn the wrong techniques first. Those techniques are there because they are usually necessary to do a particular task or tasks (and often should only be used by the expert who knows the tradeoffs already but almost never by someone who is learning). But they are often used for tasks where other better techniques should be used.

I downvote bad SQL code when it is a SQL antipattern (such as implicit joins) and there is a better way to do it. I downvote when the code needs to consider edge cases (say divide by zero) and doesn't. The down vote is the best way we have of letting the OP know there is a better solution. Given four working solutions, how is he to know which one is better to use and which one is dangerous to use as it is written? We are trying to be the source for best practices, so poor practices that appear to work but cause other problems get downvoted in pretty much all the tags.