Anti-Pattern Seen Here and at Similar Sites
-
I keep seeing a similar post/response pattern here at The Code Project and I want to point it out and solicit everyone's thoughts. First, someone will post an article (or blog, tip. etc.) that presents a snippet of potentially useful code. This is not done in the context of giving architectural advice, but in the spirit of presenting something that proved useful in at least one application. In response, someone will post criticism that attempts to find bad architectural advice in the original post, or assumes a certain architecture and then points out the code's deficiencies in that (presumably favorite) architecture. One recent example started with this tip[^]. It shows code that blocks the current thread for a specific amount of time. I did not attempt to use the code, but it looked like fairly portable C code. To me, it seemed like something that might be used for low-level coding, e.g. to time events deterministically in a non-multiprocessing environment. The tip is not a "5" in my opinion. Some context, in particular some explanation of how / why one might use the code, is needed. But I was surprised by the feedback the tip got. The suggestion was made that the tip was "completely useless" because it did not support command line arguments. Of course, command line arguments may or may not even exist on the platform one is targeting. Even if they do exist, someone had to write them. This is true of each new platform, and much of this work is done using a dialect of C that is not so different from what was presented in the tip. I understand the rationale behind the criticism. The snippet provided does not belong, for example, in a web app or database client, and this seems to be what many programmers find themselves engaged in writing. This does not make it "utterly useless," though, and the assumptions made in declaring it so are breathtaking in scope. Mentioning command line arguments assumes the existence of an OS with a command shell, which is further capable of starting parameterized executables. We all own a device that has these things, but we also own dozens of software-consuming devices that do not. Perhaps the issue here is the assumption that we are all using .NET or Java and have no desire or plan to use anything else. I do not think this assumption is valid, and (relatedly) I disa
-
I keep seeing a similar post/response pattern here at The Code Project and I want to point it out and solicit everyone's thoughts. First, someone will post an article (or blog, tip. etc.) that presents a snippet of potentially useful code. This is not done in the context of giving architectural advice, but in the spirit of presenting something that proved useful in at least one application. In response, someone will post criticism that attempts to find bad architectural advice in the original post, or assumes a certain architecture and then points out the code's deficiencies in that (presumably favorite) architecture. One recent example started with this tip[^]. It shows code that blocks the current thread for a specific amount of time. I did not attempt to use the code, but it looked like fairly portable C code. To me, it seemed like something that might be used for low-level coding, e.g. to time events deterministically in a non-multiprocessing environment. The tip is not a "5" in my opinion. Some context, in particular some explanation of how / why one might use the code, is needed. But I was surprised by the feedback the tip got. The suggestion was made that the tip was "completely useless" because it did not support command line arguments. Of course, command line arguments may or may not even exist on the platform one is targeting. Even if they do exist, someone had to write them. This is true of each new platform, and much of this work is done using a dialect of C that is not so different from what was presented in the tip. I understand the rationale behind the criticism. The snippet provided does not belong, for example, in a web app or database client, and this seems to be what many programmers find themselves engaged in writing. This does not make it "utterly useless," though, and the assumptions made in declaring it so are breathtaking in scope. Mentioning command line arguments assumes the existence of an OS with a command shell, which is further capable of starting parameterized executables. We all own a device that has these things, but we also own dozens of software-consuming devices that do not. Perhaps the issue here is the assumption that we are all using .NET or Java and have no desire or plan to use anything else. I do not think this assumption is valid, and (relatedly) I disa
_beauw_ wrote:
The suggestion was made that the tip was "completely useless" because it did not support command line arguments.
Actually, the comment was that it was completely useless because it has "No cmd line params, no threading, no nothing. Just a while loop and hardcoding." Which is pretty accurate. So what's the redeeming quality in this? That someone had to write it? That it saves people time if they can't quite remember how many seconds are in a minute? Also, good luck having that countdown timer ever finish if the program burps for a couple seconds at exactly the wrong point or gets suspended or whatever and suddenly x_seconds is > count_down_time_in_secs, because WHOOPS time_left is an unsigned int and can't handle the truth that it missed its one second window to finish. This is the code snippet you choose to defend?
- F
-
_beauw_ wrote:
The suggestion was made that the tip was "completely useless" because it did not support command line arguments.
Actually, the comment was that it was completely useless because it has "No cmd line params, no threading, no nothing. Just a while loop and hardcoding." Which is pretty accurate. So what's the redeeming quality in this? That someone had to write it? That it saves people time if they can't quite remember how many seconds are in a minute? Also, good luck having that countdown timer ever finish if the program burps for a couple seconds at exactly the wrong point or gets suspended or whatever and suddenly x_seconds is > count_down_time_in_secs, because WHOOPS time_left is an unsigned int and can't handle the truth that it missed its one second window to finish. This is the code snippet you choose to defend?
- F
I know the tip is a sloppy one. It was probably a bad choice of example on my part. The exact bug you point out is a severe one, and can happen on a wide variety of platforms, even single-process ones. I do not think that really affects my argument though. The issue for me is not the quality of one particular tip, it is the nature of the criticism leveled at it. No one posted a response to the tip explaining its bug(s), or why it does not work well in a multiprocessing environment. The response was (paraphrasing) "this is garbage because it doesn't have command line arguments." And I am sure an equal number of people looked at the tip and asked "where's the GUI?" In my original post I wanted to use someone else's tip, to make my point more objective. But perhaps one of my own tips[^] is a better example. In the tip, I provided a signature-compatible GDI+ replacement for GDI's
StretchBlt()function, which adds anti-aliasing. There are a variety of potential issues with what I posted: it is not particularly fast, a full rewrite might be better than simply dropping in a replacement function, etc. I expected criticism on these points. However, the nature of the actual criticism I got was a bit unexpected. Someone posted a response with the subject line "Just use Bitblt of GDI in WM_PAINT, resize at other." In other words, the suggestion is to draw the image at its native resolution inWM_PAINTand then resize it using other (unspecified) means. You can read my response to this post at the tip itself, but in short I do not see whereWM_PAINTnecessarily enters the discussion... this is a classic example of the anti-pattern I pointed out. Of course, relying on some other unspecified magic to do the actual work of resizing the image (the whole point ofStretchBlt()) is not valid, either. To summarize: when I post code, I am not necessarily suggesting an architecture. In criticizing my code, be brutal; point out bugs, potential optimizations, etc. But please do not place my code into some assumed architectural context without a valid reason.