• LCrawford (unregistered)

    These left behind comments are a great meta-comment about yesterday's "Leave some comments behind"!

    TypesScript For The Win!

  • Best Of 2021 (unregistered)

    To quote Robert Martin in his book Clean Code: "A truly awful example of disinformative names would be the use of lower-case L or uppercase O as variable names, especially in combination. The problem, of course, is that they look almost entirely like the constants one and zero, respectively."

    Or you could use a font that allows you to differentiate. 'L' is a perfectly cromulent name for a length variable that's only used in a local context. Use a font where 1 has a nice top bar and l doesn't and you're fine.

  • NoLand (unregistered)

    BTW, "von hinten durch die bRUst (not "burst").

  • (nodebb)

    "This line could be replaced by number |= 0x2000." NOPE NOPE NOPE (at least not provably so from the presented info...

    If number is bigger than a short, then the OP code will only write to those memory locations that are within the short. The "simplified" code will write to all of the memory covered by number...

    Now consider if number is "placement new" over a 32 bit IO port....

  • Vilx- (unregistered)

    "Which brings us to TRWTF, which forever and always will be how JavaScript handles types and type-coercion."

    Ehh... have you heard of a little thing called "PHP"?

  • RLB (unregistered) in reply to TheCPUWizard

    "This line could be replaced by number |= 0x2000." NOPE NOPE NOPE (at least not provably so from the presented info..

    Erm, yep yep yep. Because:

    number is defined as an unsigned short.

  • Mr Bits (unregistered)

    In the C code example: taking the address of a variable makes the compiler place that variable in memory (rather than in a CPU register). There may be some value in that.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Mr Bits

    Any compiler worth its salt will optimize away the *&x into just x and avoid spilling it to memory unnecessarily. If you really need to ensure that the value is stored into memory and not a register (e.g. for memory-mapped I/O), you'd typically declare the variable as volatile.

  • Dave Aronson (google)

    tern one type into another

    I C what you did there....

  • (nodebb)

    "Strongly typed" and "loosely typed" are not opposites. The opposite of strongly typed (values have a specific, enforced type) is weakly typed (values do not have an enforced type). Strictly typed (variables have a declared type) is the opposite of loosely typed (variables don't have a declared type). C is a strongly typed and strictly typed language. JavaScript and PHP are weakly typed and loosely typed languages. Python is loosely typed, but it's also strongly typed; you can assign values of any type to a variable, but if you try to use a value of a type that isn't expected, such as 1 + "2" (which works, for certain values of "works", in weakly typed languages like PHP and JavaScript), you get an error.

  • Brian (unregistered)

    The ((foo)&x) thing is a standard trick in C to force a type conversion when a standard cast won't work. It basically says "take this group of bytes that was declared as type A and treat it as type B instead". It's incredibly dangerous and smelly, but hardly uncommon. C++ added a specific keyword for that operation: reinterpret_cast.

    But speaking in more general terms of the story, I once had a co-worker who was super clever. He really liked the loose typing of PHP but had to work in C++. So what did he do? Created his own custom container library that handles everything as byte arrays, so you can store anything you like in any sort of combination without having to worry about all those annoying compiler errors. When you want to retrieve something from the container, just cast it back to whatever type it was when it went in. Simple!

  • Brian (unregistered) in reply to Brian

    It would really help if this comment engine had a preview button, so I could see that it would turn my stars into italics...

  • DanK (unregistered)

    The first one looks like the result of some refactoring. My guess is that the argument used to have a different type and the cast was needed. When the type was fixed, the rest of the code was not cleaned up.

  • Scott (unregistered)

    No, I don't wonder what the developer was thinking in Sashi's example. The answer is nothing. Might be kind of a zen thing.

  • (nodebb)

    TRWTF isn't so much Javascript and its idiotic type system, rather its popularity in non browser usages.

  • ooOOooGa (unregistered) in reply to Dragnslcr

    While I don't like the type juggling of PHP, it only blows up just often enough to keep you paranoid. When I run 1 + "2" on PHP, I get an integer type with value 3. I'm not sure what else you would expect.

    And running 1 + 'two' throws a TypeError.

  • Best Of 2021 (unregistered)

    What happened with the comments here? O.o

  • Naomi (unregistered) in reply to Brian

    It's Markdown. Yes, there should be a previewer built into this site (Alex!!!), but there are Markdown previewers online, if that helps.

    For this specific issue, just get in the habit of throwing backticks around your code snippet: `(*(*foo)&x)`=> (*(*foo)&x)

  • Duke of New York (unregistered) in reply to ooOOooGa

    I could expect:

    • 1 (all strings evaluate to zero as in BASIC)
    • NaN (all strings evaluate to NaN, because they aren't)
    • "12" (integers converted to strings as in Java and, by inheritance, JavaScript)
    • empty string (strings are character sequences and addition is offsetting, as in C)

    That should make it clear enough that there's nothing "obvious" about a particular expectation outside of habit. This is also why most criticism of implicit type conversion falls under "can't be bothered to RTFM, and proud of it."

  • (nodebb) in reply to ooOOooGa

    When I run 1 + "2" on PHP, I get an integer type with value 3. I'm not sure what else you would expect.

    51 if it's going to return an integer. If it's going to return a string, either "12" or "3" would seem reasonable.

    For definitions of "reasonable" that include being able to add ints and strings, ew.

  • Naomi (unregistered)

    This is also why most criticism of implicit type conversion falls under "can't be bothered to RTFM, and proud of it."

    I really don't think that's fair. I can reason about types in Javascript (usually), but that doesn't make them intuitive. The problem isn't so much that implicit conversion happens as when the rules start interacting, especially in a dynamic language where there aren't any type declarations to help make sense of them. Just because someone knows what the type conversion rules are doesn't necessarily mean they can reason backwards about why they're seeing some behavior, or easily grok all the corner cases of some expression.

    In other words, RingTFM tells you what the rules are, but the complaints usually come down to unintuitive interactions. It's not a fair comparison.

  • mushroom farm (unregistered) in reply to Best Of 2021

    boy, I'd hate to be a coworker who chooses the "wrong" font and is then not able to read such lousy variable names

  • tbo (unregistered) in reply to Vilx-

    I'm kind of tired of the hate the people heap on PHP. The language makes sense for its original purpose, which was to handle submitted HTML forms.

    When you submit an HTML form, all the data gets passed as a string. The language, much like web browsers parsing HTML, is designed to try to keep going as best it can, and not to die.

    If you have a web form that asks for two fields so it can add them, $field1 + $field2 gives you the answer. You don't have to try to cast them and throw an exception or some nonsense if you can't make them into numbers, because if "a" + "b" = 0, who cares?

    Now, PHP certainly outgrew its original humble origins. Being a language that's easy to learn was both a blessing and a curse for it, as it ended up being used well beyond the expectations of its original creator, I'd wager. And now newer versions are starting to support type declarations and the like as it matures into a more "serious" language. It's honestly a little annoying now and then.

    But a lot of its design choices make sense in context.

  • tbo (unregistered) in reply to Bim Zively

    Why would you ever expect a string when using the '+' operator?

  • Loren Pechtel (unregistered)

    I'll second DanK--that was my first thought, also. The parameter used to be something else. It's not insane, my current project has it's own version of a data reader--because underneath it has both SQL and MySQL components. In almost all cases only the lowest level even has any idea of what database it's talking to.

  • Sole Purpose Of Visit (unregistered) in reply to Best Of 2021

    Or, of course, you could completely ignore Robert Martin.

    It's a personal choice, I understand; but on the whole, bloviating twits who spend their time writing "how to" books and articles and going on the lecture circuit, with no discernible experience in the field, tend to be less than convincing.

    There are plenty of other authorities (from whose thoughts Mr Marin presumably borrows) to whom I will listen. But Martin? No. I think not.

  • Sole Purpose Of Visit (unregistered) in reply to Brian

    That's going to be highly entertaining when your cretin coworker tries to send the byte stream over a network to an other-endian machine, isn't it?

  • (nodebb) in reply to tbo

    The whole "PHP made sense" argument isn't without merit, however that's not a point most people argue with. Nobody says go jail creators of PHP for their past deeds. The question is, what's the point of using it today, given many far superior alternatives? The answer may be, it's easy and more suitable for the task at hand, to which i say, if you want to write code, please learn first. If you don't understand types and casting etc, do not be a programmer.

  • mihi (unregistered)

    As C# allows to override the typecast operator (and you will see it in action when working with COM or OLE stubs), I am not 100% sure that a typecast to itself is always a no-op. But for SqlDataReader, I hope it is.

  • Duke of New York (unregistered)

    Robert Martin's practical experience is listed on LinkedIn and attested there by other users. He acquired it before it was assumed that anyone competent in software development must have a published portfolio of code, and working on the kind of corporate-facing projects that mostly wouldn't be published even today.

    OTOH I have my own unpleasant experience with "mentors" who get too enamored with their own system and adages, as well as interviewers who think that being able to expand SOLID is a necessary qualification. Screening developers according to whether they've read the appropriate "great books" (CC, GoF, DDD) mainly achieves ideological conformity, not engineering quality.

  • (nodebb)

    Javascript: [] + {} {} + [] One gives 0, the other gives "Object".

    But the only case where it has actually affected me is type casting of Promises. Things like "if(x)" and forgetting that x is a promise, not a plain boolean.

    With static type checking that error cannot happen. But really, I'd much prefer for Promises to be awaited automatically when you try to interpret them as a value. Sadly without what would basically be static type checking, this would also be extremely inefficient, because suddenly next to everything would have to be checked for being a promise.

    Addendum 2021-03-10 16:58: I just realized, that I was basically describing Haskell'ish lazy evaluation...

  • Bart (unregistered)

    'von hinten durch die Burst ins Auge' should read 'von hinten durch die Brust ins Auge'...

  • Frank Wilhoit (google)

    Strong typing is like violence: if it isn't solving all your problems, you must just not be using enough of it.

  • (nodebb) in reply to ooOOooGa
    While I don't like the type juggling of PHP, it only blows up just often enough to keep you paranoid. When I run 1 + "2" on PHP, I get an integer type with value 3. I'm not sure what else you would expect.

    It was more of a dig at JavaScript, where 1 + "2" gives you "12".

  • löchleindeluxe (unregistered)

    Huh. I am now pondering x?true:false vs. !!x in terms of clarity.

  • foxbow (unregistered)

    The *((unsigned short *) &number) = number | 0x2000; construct looks a lot like someone trying to assign a new value to a const.

  • Tim (unregistered) in reply to löchleindeluxe

    There are many legitimate cases in javascript where you might want to turn something from just "truthy" into an actual true or false (to serialize it into json for example). using a double-not (!!) is one of the approaches recommended on MDN. It works with C as well

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to TheCPUWizard

    If number is bigger than a short, then the OP code will

    ...become endian dependent. Hello nasal demons!

  • (nodebb) in reply to mushroom farm

    "I'd hate to use the wrong font" If Apple can't get it right when talking about how they "c l i c k" how do you expect to get the right font choice? https://techcrunch.com/2016/02/25/more-to-love-with-every-dick/

  • (nodebb) in reply to TheCPUWizard

    It's specifically stated to be C in the article. Why do you assume it is C++?

    Anyway, the two statements are not identical unless the underlying machine is little endian or number is the same size as short.

Leave a comment on “A Type of Code”

Log In or post as a guest

Replying to comment #524249:

« Return to Article