4 ms·

The removal of "This..." from the title here really confuses it. With "This", it's obvious the title is "(This code) smells of desperation". The submitted tit

The removal of "This..." from the title here really confuses it. With "This", it's obvious the title is "(This code) smells of desperation". The submitted title is ambiguous; it could mean "(Code smells) of desperation".

Lewton 3y ago
I clicked expecting a joke article about Code Smells, I was a little disappointed
- hinkley 3y ago
  Thank you both for saving me early morning disappointment.
  - dmvdoug 3y ago
    It was a good read nonetheless!
    - veave 3y ago
      os2museum is a good read always.
hinkley 3y ago
Code Smell is an industry accepted term. I am unclear how any other interpretation of the modified title could be expected.
- macintux 3y ago
  Alternative interpretation based on the mangled title: here are things to look for in any code base which indicate the programmer was desperate.
- benchaney 3y ago
  Well, interpreting the title in that way is incorrect, so it seems like GP kind of has a point then.
- zztop44 3y ago
  All code smells of desperation.
  - veave 3y ago
    That's how I interpreted the title.
    - michaelcampbell 3y ago
      >> All code smells of desperation. > That's how I interpreted the title. That's my point - even that is ambiguous. Do you mean, "There is no code that doesn't smell of desperation" or "Of all the code that exists, herein lies the complete subset of it that smells of desperation" eg: (All code) smells of desperation vs. All (code smells) of desperation.
- Narishma 3y ago
  You just proved OP's point since you misunderstood what the original title was.
- Karellen 3y ago
  the "smells" in the industry term "code smells" can function as both a verb and a noun. As a noun, it can describe specific ways that hypothetical code might not follow best practices. For instance, code fragments that have been copy-pasted many times rather than refactored into a function, is a code smell. The use of many global variables is a code smell. Together, these are "code smells". As a verb, it describes specific code which exhibits these sorts of attributes. A particular source file can smell. The code... smells. The phrase can also be used adjectively, to say that code is smelly. The title "Code smells of desperation" could imply the noun form, in which an article discusses various code smells which could be a general indication that a hypothetical code base might be in desperate shape. Or that the team maintaining it is. It is an article about smells, in code. Whereas, "this code smells of desperation" uses the verb form to indicate that the article is about a particular code base which appears to be in desperate shape, because of the smells it specifically gives off. It is an article about code, which smells.
bin_bash 3y ago
The submitted title might very well have been "This code smells of desperation.". HN has some strange rules that edit submitted titles like stripping "10" or "How to"
- kgwgk 3y ago
  It was already annoying that titles can be changed by a moderator without leaving any trace and now titles are also being mutilated automatically at submission time into something that may or may not make sense. At least in this case the submitter may notice what happened and change it back.
  - sixothree 3y ago
    That has certainly made finding something in my history difficult more than a few times.
  - bin_bash 3y ago
    Well for what it’s worth this certainly isn’t new
    - kgwgk 3y ago
      Recency is relative.
- dang 3y ago
  They would seem less strange if you saw a list of the baity titles that get de-baited that way. Maybe we should publish that. "How to" doesn't get edited out. Certain other leading hows do.
  - bin_bash 3y ago
    I feel like it’d definitely help to know what the rules are. Might make it better to editorialize slightly and avoid having it happen automatically
graton 3y ago
This comment reminds me of those Amazon reviews that give a product 1-star because Amazon had a shipping issue. Yeah, sorry the product wasn't able to get to you but you aren't helping me figure if the product itself is any good or not.
- russh 3y ago
  Like the time I ordered some slate coasters but received an envelope of slate chips and fine powder. I was not able to leave a review that mentioned that the seller just wrapped the coasters in a paper towel and tossed the coasters in a sturdy envelope.
picometer 3y ago
I was also slightly disappointed not to find a discussion of <code smells>, but the post is interesting, and we can still discuss code smells here. The post author (Michal Necasek) states, about the WIN87EM.DLL code: > It bears all the hallmarks of code that was written, rewritten, rewritten again, hacked, tweaked, modified, and eventually beaten into submission even if the author(s) had no real idea why it finally worked. From what I gather, here are those hallmarks: - Looping a no-op action, presumably to slow things down. - Unnecessarily performing actions multiple times. This happens for three things: (a) writing a zero to an I/O port to clear something; (b) executing an instruction to clear exceptions; and (c) repeating the aforementioned no-op loop at different points. - Saving a status in a separate location, only to reinstate it to its original location after clearing things out. - Communicating procedure state (an EOI, “end of interrupt”) to one entity (the master interrupt controller) but not another (the controller’s slave). Furthermore, this “end” signal was sent near the beginning of the procedure. (This final point is my own observation and not explicitly called out by the author. Perhaps it’s common and not “smelly” for interrupt handlers to do this up front.) I’ve tried to reframe the technical terms as actions and signals in a way that could be recognizable to devs of higher-level systems. My familiarity with OS-level systems is minimal so my interpretations could be a little wrong. But despite my lack of knowledge, and with the author’s help, it does seem clear that there were serious timing and state related bugs here. And as a dev at other levels of the stack, I can relate: it’s very hard to reason about async global state! And this code’s responsibility was handling math errors, not timing errors. It is - or, perhaps, should be - the responsibility of the OS to orchestrate these things appropriately so that math libraries can focus on math stuff. So my takeaways, for “code smells of desperation”, would be: - There are violations of module responsibility. - There are modifications of process timing with no discernible reason. - There are modifications of status/environment/state with no discernible reason. - And finally, other experts (in this case, the post author) can’t make sense of the code.

Lewton 3y ago

I clicked expecting a joke article about Code Smells, I was a little disappointed

hinkley 3y ago
Thank you both for saving me early morning disappointment.
- dmvdoug 3y ago
  It was a good read nonetheless!
  - veave 3y ago
    os2museum is a good read always.

hinkley 3y ago

Code Smell is an industry accepted term. I am unclear how any other interpretation of the modified title could be expected.

macintux 3y ago
Alternative interpretation based on the mangled title: here are things to look for in any code base which indicate the programmer was desperate.
benchaney 3y ago
Well, interpreting the title in that way is incorrect, so it seems like GP kind of has a point then.
zztop44 3y ago
All code smells of desperation.
- veave 3y ago
  That's how I interpreted the title.
  - michaelcampbell 3y ago
    >> All code smells of desperation. > That's how I interpreted the title. That's my point - even that is ambiguous. Do you mean, "There is no code that doesn't smell of desperation" or "Of all the code that exists, herein lies the complete subset of it that smells of desperation" eg: (All code) smells of desperation vs. All (code smells) of desperation.
Narishma 3y ago
You just proved OP's point since you misunderstood what the original title was.
Karellen 3y ago
the "smells" in the industry term "code smells" can function as both a verb and a noun. As a noun, it can describe specific ways that hypothetical code might not follow best practices. For instance, code fragments that have been copy-pasted many times rather than refactored into a function, is a code smell. The use of many global variables is a code smell. Together, these are "code smells". As a verb, it describes specific code which exhibits these sorts of attributes. A particular source file can smell. The code... smells. The phrase can also be used adjectively, to say that code is smelly. The title "Code smells of desperation" could imply the noun form, in which an article discusses various code smells which could be a general indication that a hypothetical code base might be in desperate shape. Or that the team maintaining it is. It is an article about smells, in code. Whereas, "this code smells of desperation" uses the verb form to indicate that the article is about a particular code base which appears to be in desperate shape, because of the smells it specifically gives off. It is an article about code, which smells.

bin_bash 3y ago

The submitted title might very well have been "This code smells of desperation.". HN has some strange rules that edit submitted titles like stripping "10" or "How to"

kgwgk 3y ago
It was already annoying that titles can be changed by a moderator without leaving any trace and now titles are also being mutilated automatically at submission time into something that may or may not make sense. At least in this case the submitter may notice what happened and change it back.
- sixothree 3y ago
  That has certainly made finding something in my history difficult more than a few times.
- bin_bash 3y ago
  Well for what it’s worth this certainly isn’t new
  - kgwgk 3y ago
    Recency is relative.
dang 3y ago
They would seem less strange if you saw a list of the baity titles that get de-baited that way. Maybe we should publish that. "How to" doesn't get edited out. Certain other leading hows do.
- bin_bash 3y ago
  I feel like it’d definitely help to know what the rules are. Might make it better to editorialize slightly and avoid having it happen automatically

graton 3y ago

This comment reminds me of those Amazon reviews that give a product 1-star because Amazon had a shipping issue. Yeah, sorry the product wasn't able to get to you but you aren't helping me figure if the product itself is any good or not.

russh 3y ago
Like the time I ordered some slate coasters but received an envelope of slate chips and fine powder. I was not able to leave a review that mentioned that the seller just wrapped the coasters in a paper towel and tossed the coasters in a sturdy envelope.

picometer 3y ago

I was also slightly disappointed not to find a discussion of <code smells>, but the post is interesting, and we can still discuss code smells here. The post author (Michal Necasek) states, about the WIN87EM.DLL code: > It bears all the hallmarks of code that was written, rewritten, rewritten again, hacked, tweaked, modified, and eventually beaten into submission even if the author(s) had no real idea why it finally worked. From what I gather, here are those hallmarks: - Looping a no-op action, presumably to slow things down. - Unnecessarily performing actions multiple times. This happens for three things: (a) writing a zero to an I/O port to clear something; (b) executing an instruction to clear exceptions; and (c) repeating the aforementioned no-op loop at different points. - Saving a status in a separate location, only to reinstate it to its original location after clearing things out. - Communicating procedure state (an EOI, “end of interrupt”) to one entity (the master interrupt controller) but not another (the controller’s slave). Furthermore, this “end” signal was sent near the beginning of the procedure. (This final point is my own observation and not explicitly called out by the author. Perhaps it’s common and not “smelly” for interrupt handlers to do this up front.) I’ve tried to reframe the technical terms as actions and signals in a way that could be recognizable to devs of higher-level systems. My familiarity with OS-level systems is minimal so my interpretations could be a little wrong. But despite my lack of knowledge, and with the author’s help, it does seem clear that there were serious timing and state related bugs here. And as a dev at other levels of the stack, I can relate: it’s very hard to reason about async global state! And this code’s responsibility was handling math errors, not timing errors. It is - or, perhaps, should be - the responsibility of the OS to orchestrate these things appropriately so that math libraries can focus on math stuff. So my takeaways, for “code smells of desperation”, would be: - There are violations of module responsibility. - There are modifications of process timing with no discernible reason. - There are modifications of status/environment/state with no discernible reason. - And finally, other experts (in this case, the post author) can’t make sense of the code.