- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Re: iMalc
This whole subthread vaguely disturbs me.
Let me reiterate the original point: there is never a good reason for your program to contain "11001101".
Firstly: whats wrong with "int i = 0xCD;"? Or "int i = 0xCD; // 11001101 binary", if you think that people reading the program might not know what "0xCD" means - assuming there is a context in which somebody might reasonably be editing a program containing the presumably critical binary number "11001101" but somehow not know that its just 0xCD.
Secondly: if you write "const char *s="11001101";", what do you think happens when you try to chop it, or splice bits? The underlying machine operations are exactly the same as if you had written "const uint8 *a = {1,1,0,0,1,1,0,1};" and performed the corresponding array operations; moreover, the latter is more readable, since it makes it clear that the intent is to create an array of values and not a string (there was a time when you would, as a programmer, have been expected to know the difference).
Some things are done for a reason: critical optimization, where the code just has to run fast, and everything else (including human-readability) is secondary; critical maintainability, where the code just has to be readable and minimally error-prone, and everything else (including run-time performance) is secondary; and so on.
And other things are done for no reason other than that the person coding them is utterly effing incompetent. I would argue, IMVHO, that implementing something in a given way because it lets you abuse a feature of the particular language youre using in order to avoid reading the language ior standard library reference, falls into this latter category. And if you have done it that way because the language youve chosen doesnt let you do it the straightforward way - well, that would only make it worse, wouldnt it? (Hint: an idiotic decision to use an inappropriate language is no less idiotic because the programmer did not make it personally.)
Specifically, then: using strings to represent binary numbers is an abortive attempt at syntactic sugar that makes the program less comprehensible to both humans and computers.
TL;DR: when one is confronted with code that is clearly Just Plain Bad, with no redeeming qualities whatsoever, one calls it as such.
Admin
Or perhaps a binary column (BLOB, IMAGE, w/e)? There is no excuse for storing 82 bits of data using 82 bytes of storage.
Admin
If I were assigned to maintain that code, then:
If I had enough savings to live for 3 months, I would quit on the spot.
If I did not have that savings, I would immediately use as much vacation as I could, and very aggressively look for a new job.
"Do you not consider refactoring part of your job ?" is a total strawman. Just because refactoring is part of my job, that doesn't mean I can't put limits on what kinds of refactoring (or any other task that's "part of my job") that I'm willing to do.
And no, the fact that somebody would walk away from a total shit job does not make them not worth employing.
Admin
Right. Because this site is all about productivity and providing useful information.
Admin
No er... actually you can not. Unless you don't use system functions at all but this would be very simple code. Names and patterns are just too convoluted to make clean and elegant code possible.
Admin
This code doesn't just need refactoring - it needs an enema!
Admin
It depends.
If one is assigned to refactor that code, then, certainly, refactoring it is within the scope of the employment.
If one is assigned to rewrite that functionality, that is certainly within the scope of employment.
In either situation, or in the case where I was to do one or the other, based upon my expert opinion which was a better plan, I would not have a real issue with it.
I'd personally not have a problem with it if I were allowed to refactor it - but it had to be on my time. If I'm going to be working with this thing regularly, there's a quality of work environment aspect that would, IMHO, be worth a couple of weekends of refactoring work. (I've done it before - and I expect to do it again.)
If, on the other hand, I was required to maintain that code without gratuitous refactoring, I would consider my options.
If I was required to maintain that code, and maintain its current style (no refactoring each section I'm required to update), I would probably actively seek alternative employment.
There are people who are far less cautious than me who would simply quit - and I wouldn't complain about it, if they were not allowed to fix the problem on company time.
Now, those who would actually quit over just having to interact, however briefly, with said code, like the grandparent poster indicated - I agree with you on his claimed prima donna status.
Admin
I seem to recall having worked with PHP version 3 code which did a fair amount of LDAP interactions without resorting to any system calls. At the time, it looked like we could actually get it to look somewhat elegant if we upgraded to using PHP 4.
However, after doing a cost-benefit analysis, and factoring in that the team was entirely composed of Perl programmers, who had only picked up PHP for this particular job (since the PHP guy had left), we chose to go with Perl instead. Only people who've had regrets about that choice are the people who've since tried to get us to replace the pages with ASP, ASP.NET, or Java code - they've all been shot down because our Perl pages have no visible issues, and generally respond several times faster than any of the ASP, ASP.NET, and JSP pages elsewhere in the company.
So, I guess, take my first paragraph with the grain of salt that this comes from someone who feels it's possible to make Perl code look elegant and clean - but it's also from someone who takes the time to learn how to actually use the languages he works with, rather than just abusing the shell scripting hooks present.
Admin
Beautiful answer; thanks for taking the time to post it.
Admin
Might this sequence of 1 and 0's be the original core of the internet? If the internet ever crashes this PHP page can be run on a local web server to restart it?
Admin
really interesting contribution to the thread you've made procedural. i only disagree with you calling the first guy a prima donna. like someone else pointed out, i think he didn't literally mean he'd quite the instant he saw this code. it was just a hyperbolic expression of his disgust at the code. and i think we can all agree that the code is disgusting.
Admin
hmm, after reading the code 5 times (damn my head hurts) i think i reverse-engineered it! Voila Soo, i guess it's a very 1337 way of product extras i.e. If the field has 0 at index 5 then this product doesn't have the fifth feaure
Yeah, like, i admit it, i have written similar shit code :)
Admin
That was just about the most frightening thing I've ever seen. Absolutely the most pain I have ever felt while scrolling code as fast as my computer would let me. How fast is that? Not fast enough...
Admin
AWESOME
Admin
Death to high level coding. The ASM code needed to extract data from that string would be shorter than the string itself.