Assignment and comparison in the same statement can be dangerous, unless one knows the compiler being used very well or then making certain that optimization is off as one can get some very weird and unexpected results. Another problem with == is when comparing "real" number types. Quote from the GNU C Reference manual: This has caught me out before on several occasions so now I'm pretty paranoid about it.
That's bog standard shorthand syntax, part of the standard in C derivities ever since ANSI C back in the late 1980s. It is shorthand for: IF y == z THEN x = a ELSE x = b Its not a hack. Also, in the C derivatives it is perfectly fine (and part of the standard) to do things like: x = (a == b); to mean set x to be true if a and b are equal, IF (x = a == b) ... to mean assign x to be true if a is the same as b but also move on to do whatever is after the IF (although I never use this shorthand because it feels to much like side-effects and isn't very readable, especially if you do something proper dirty like: IF (x = y = z = a == b AND i ==j) .... However the first example is fine and I use it all the time. It is called the 'ternary operator'. Its not a side effect, its part of the standard. I'll have to leave this thread for a while now, because I lose my ability to think in any human language once my code head comes online
I have to agree with you about the syntax. The problem comes in when the variables "a" and "b" in a==b have been declared as "real" numbers as opposed to say integers. I know what you mean. During the course of the day, I can be coding in C++ in the morning, then have to "touch up" the resulting binary code using a hex editor as compilers sometimes make a mess of vector tables for projects using small microprocessors (or one wants to "take over" an interrupt). Later in the afternoon may have to do some Perl (we use it together with MySQL) then still have to attend a meeting, by which time my head is spinning so fast that I just sit there in a "daze".
Agreed. I suspect it must rate in the top three of common mistakes when coding. Been there, done that, slapped myself when discovered the blunder.
.. or, worse, a compiler #define expression and add to that Javascript's tripple-equal-sign logical operator ... Write-only languages in fact ...
A necessary evil that I prefer to avoid where possible. People bang on about 'web2.0', but I hate javascript. Its just so bad. If I can shell it out to the server with the same result, that's what I'll do. I've never seen the logic in a mostly javascript web app. Apart from the fact that javascript security, despite what the 'standards' say, is pretty much non-existent, and the fact that different browsers have different implementations of both the language and the DOM (which we can get round for the most part with jQuery), and the fact that all your code comes down to the client for all to see (and learn from, and look for weaknesses in), I just hate it just for what it is. I mean, null was invented for a reason. null means 'I have no data for this, I don't know what it is because its never been assigned, it is not a value, it is the total absence of anything'. Its very useful. So why then does JS insist on also having 'undefined'? undefined, which means 'I don't know what you intend with this, I am the absence of anything at this stage', is conceptually, for all practical purposes (ok I know the academic difference), the same as null. Yet it is not the same as null. And why can I create a variable and not give it a type? Why should I trust a compiler/interpreter to work out what type it is and change it willy-nilly as the code runs? If I need an integer, I like to say that I need an integer. I don't want to say 'give me a variable that can be anything, or in fact can change on a whim'. Ok, I know this is true of many other weak languages, but fortunately I generally get the opportunity to choose to never use other weak languages. The nature of my job means I am sometimes stuck with JS for certain tasks. I much prefer real C descendent. If I need an integer and then later in code assign something to it that is not even an integer, I'll not get a runtime error, it just wont even compile. It will say 'hey, daft lad, you can't assign this to that, its the wrong datatype'. Then I know that at least the most common types of runtime error will be spotted before I even test my code. So there's my JS rant. Best nobody mentions CSS
Not a big fan of JavaScript and use it only for small client side scripts so never had occasion to use the === (Strict Equality). The #define can get tricky due to "expansion" in the preprocessor.
Nope. VB script and classic asp, as awful as it is, has some logic to it. CSS on the other hand is just pure witchery. What's that? You want me to set the height of this element? Mwahahaha, I'm not going to do it. I'm not even going to tell you why, I'm going to wait til you realise that you haven't got display: block; which you usually don't need but somebody else has set display: inline; on an element further up the tree. What's that? You want it to be 200px wide with a 2px border? I'll just make it 204px wide then, unless you're in Firefox, where I'll render different, unless you also mess about with the box model settings, which I'll overlook on a browser that doesn't support the particular box model attributes you set unless you remember to use lots of different ones to cover all browsers. What's that? float: left; ? Well I might, float it left, if I'm either implicitly, explicitly or through inheritance display: block; and I'll also float all the contents left unless you say otherwise, but if you say otherwise, remember to clear floats first otherwise I'll just randomly jumble up your content. You want the footer to stay at the bottom of the window but the main content can not be fixed size? Mwhahaha, good luck
Ha yes the joys of CSS and the way browser developers interpret standards. The real fun starts with WebGL and HTML5, it's enough to drive anyone around the bend.
Speed. Using AJAX for us is like night and day by only doing the round-trip for parts of the page. Getting JS to do that deed for us is all we need. The rest is server-side for us. Although ... I would quite like to move our page rendering to JS. We could then just ship raw data, and templates, to the Client and have it render the stuff - take the load off our servers. Not sure I want to give-away that secret though. Nor invite hacking bugs either, as you say. Us too. But what's with this "I'll centralised some code that wanders round the HTML and attaches a function to an event on bits of it" - adding a function to an OnClick event of an HREF for example. Drives me nuts. I look at the HREF in the source and there is nothing there - I have to read through reams of code to discover if there is / isn't some code that will attach a function to that HREF at startup / later (and then I don't really know because its probably being attached to all HREFs - but conditionally. So I have to run the APP and check it - even that isn't bulletproof as it's attachment may itself be "it depends") Thrown together by Summer Interns probably. We've got code here that we have lived with for years where I failed to adequately supervise the intern. Does the job absolutely fine, but it does it in Omega-fashion whereas I would have prefers an Alpha-algorithm (one of the ones not taught at Uni, even to graduates who managed to get a First - as was the case in this instance ...) I like that the definition of a variable is null, as distinct from the variable holding a value that is null. Well ... I like that if variable definition is not a requirement; but I don't like that variabels don't need to be defined, or are defined by typeless. quite. So all my code is Hungarian Notation in the hope that I will spot that an assignment of floatFoo = intBar needs, at the least, casting. Hate it. The Arty folk around me get the designers to solve problems in CSS, and the Arty CSS-heads solve the problem. There is not one single ounce of maintainability in any of their CSS code, its a series of hacks, usually built on top of Twitter's Bootsrap (which turned out, for us, to be seriously flawed in areas that Twitter doesn't actually use it) so a few days later the APP (in production) breaks somewhere else. They fix that and then rinse and repeat ... for ever. A complete regression test suite and automated testing suite would fix that. But they prefer to spend far more money doing it by hand. Every time. Not something that I have to worry about though, other than reminding them now and again how much money they waste by not having a structured process.
@Kristen, I couldn't have put it better myself. I like ajax too, but in my latest project I haven't used the technique anywhere. It comes at a price, which is worth it if the app suits, but in my latest one it doesn't really. That price is the hassle of maintaining state. Ajax making web service calls is very useful, but its a nightmare getting those webservice to maintain session state reliably. Easily overcome by passing a session token about but its just one extra thing to think about. I'd be wary of letting JS handle all the rendering. At a previous employment that was the strategy they used. Me and the two other senior developers (none of us wrote the original prototype that started the app down that path) were very vocally opposed to it because of the hassle it caused. You're putting far too much reliance on the browser and any plugins that might be installed, the hardware the user is using, the settings they may have overriden from the defaults etc. We were constantly finding this out the hard way. We had code that ran absolutely fine on every machine on our premises, then ran like a dog on client's machines, in places didn't run at all. We had customers still running IE 6, which gave us a real nightmare rendering some of the more visual components, whereas server-side you can just render an image and pump it down as is. In theory, all of these problems can be overcome, but it is my opinion that the less reliance you place on the browser, and the more you put on the servers, the more control you have over it and therefore the more likely you are to have happy customers.
Or put more simply, consider this. Lets say that we have a floating point (real) number, but to keep things simple, lets say we have a rubbish (purely hypothetical) compiler that can only go to a precision of 1 decimal place. So, we'll say this: float a = 2.1; float b = 2.1; if (((a / 2) * 2) == b) { somet(); } So, we're saying first half a, then double it, then compare the result with b. They are the same right? a / 2 = 1.05, but our compiler is rubbish and can't go to that resolution, so in our compiler, a / 2 becomes either 1.1 (if it rounds up on 5 or over) or 1.0 if it rounds down. 1.1 * 2 = 2.2, which is not equal to 2.1 (b) 1.0 * 2 = 2.0 which is also not equal to b. So, it never matches. Its not quite that simple, because on floating point (as opposed to fixed point) we can't say how many decimal places we'll get for every number (look up the IEE floating point algorithms), but in essence, I think this, in oversimplistic terms, highlights why you never use equality operators on floating point numbers. Quite apart from the technical reason, why would you want to? real numbers, by their very definition, representing linear things which in nature have potentially infinite resolution. Consider the value of Pi. You can't represent it precisely because nobody has ever worked out where it ends Or, try a more simple one. Try putting 1/3 in a real number with absolute precision. That can't be done either.
