• MiserableOldGit (unregistered)

    Why is it everything I say gets blocked for moderation, I know I like to be rude about Remy, but I thought he was being a grown-up and ignoring me ...

  • jay (unregistered)

    I'd quibble that exceptions SHOULD control flow. Just not the way it's done here. It's appropriate to write "if (!valid) throw new BogusDataException();" One of the good things about exceptions is that they jump you out of the normal flow. You don't need to wrap them if if/else's to prevent other code paths from being executed when the exception happens. The exception jumps you out of the normal flow. This can greatly reduce the complexity of the control structures, and is a Good Thing.

    Also, checking "if (message=="Nope")" is one of those fingernails on the blackboard things for me. (Do millennials understand that idiom? It occurs to me that many of them may never have seen a blackboard. But I digress.) I strenuously avoid checking for literal strings like this. The possibility of a typo is too great. I worked on a program once where a function had a parameter that was a string that was used to control processing. I think string could be "Stock", "Item", or I forget what other values. It took me a long time to finally realize that at one point the function was being called with "stock" instead of "Stock". This problem would easily have been avoided by using an enum or symbolic constants instead of a string.

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

    And yet software today uses vastly more memory and CPU power of that 10 or 20 years ago, even when providing essentially the same functionality, so I'm not convinced about the obsession with efficiency theory. I've occasionally used numerical types for values that weren't arithmetically numbers simply to give a small amount of additional type safety. If languages had the ability to specify custom string types with particular restrictions on length/ character sets etc. it might help but for whatever reason the idea has never taken off.

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

    And yet software today uses vastly more memory and CPU power of that 10 or 20 years ago, even when providing essentially the same functionality, so I'm not convinced about the obsession with efficiency theory. I've occasionally used numerical types for values that weren't arithmetically numbers simply to give a small amount of additional type safety. If languages had the ability to specify custom string types with particular restrictions on length/ character sets etc. it might help but for whatever reason the idea has never taken off.

  • Officer Johnny Holzkopf (unregistered)

    Whole regions in Germany, namely in Sachsen (Saxonia), have postal codes (PLZ, Postleitzahl) starting with a zero, there are over 1500 of such nope "invalid numbers", dood, according to the code snippet. Yes, it is probably US-centric, both in intention of the creator and the intended recipients and their copypasta use cases. Also remember recommending " Falsehoods programmers believe about addresses" - https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ - which should be a mandatory lesson before starting with any ZIP-related coding.

  • Cached Code (unregistered)

    Here it is

    https://snippets.cacher.io/snippet/566fdcaead5bf3735a77

  • (nodebb) in reply to jay

    In Austria, ZIP codes have four digits.

  • (nodebb) in reply to RLB

    I also know streets, where the numbers go up pm the left, the continue back on the other side, putting the highest and lowest number right next to each other.

    In Japan supposedly digital support for postmen took of early, because houses are numbered in the order of construction, not by position, making letter delivery a bit adventurous. Austria has something similar in villages, which often don't have street names and just enumerate the houses regardless of position.

    There's also plenty of "11a", "11b", presumably going back to a parcel being split, i.e. it cannot be represented as a numeric data type at all.

  • gnasher729 (unregistered) in reply to Anonymous Coward

    There is one problem with British developers: They often write code that mixes up UTC and local time. Because that's a mistake that they can't detect for six months of the year. US programmers doing this have their code fail instantly.

  • gnasher729 (unregistered) in reply to Meir

    In my street, about 30% of the houses have names. So sorting isn't very useful. On the other hand there are databases where you can look up the names and find the location. And some places arrange homes in strange ways. If you are at number 48, where is number 49? Could be anywhere.

  • (nodebb) in reply to jay

    I think we're discussing 2 things here. You described the UI validation where indeed a regex like \d{5} is the solution. I meant in the context of storage, once you already have the integer, then 0 <= n <= 99999 works, think check constraint.

    Another question, what's more important: index seek performance or displaying the value. If we're searching by zip all day, integer is faster. However if searching is rare and instead the value is used as a string, then string is preferable.

    Again this is purely academic, I still use strings for all geographic names including street numbers and zip codes. There are other valid reasons to use strings. I just object to the blanket notion of "no math therefore use strings".

  • RLB (unregistered) in reply to jay

    "Phone number" and "social security number" have the word "number" right in the name! How can they not be numbers?

    Fun thing, in Dutch we have two words for "number": "nummer" and "getal". A phone number is a telefoonnummer, but not a telefoongetal. You can do arithmetic (and worse) on getallen, but if you try it on nummers, you get into the problems we're having here.

  • RLB (unregistered) in reply to MiserableOldGit

    Yeah, I'm also NL

    Ever been to Urk? They have addresses like Wijk 4 13, and that's not street Wijk, number 4, suffix 13, but street Wijk 4, number 13. (And, of course, our country has several "Laan 40-45", and I suppose there are "Square of 1918" in several countries.)

  • CodeMonkey403 (unregistered) in reply to RLB

    I've had to deal with situations where the (US only) phone number has to be formatted as "(xxx) xxx-xxxx" in one place and "xxx-xxx-xxxx" in another. Lot easier to deal with if the phone number is stored with only the important parts and formatting is handled on the client side.

  • (nodebb) in reply to Prime Mover

    you sort of hope that at least some would-be British programmers may start to approach the question of postcodes and telephone numbers with a little more insight

    Certainly in the case of post codes. British postcodes contain letters and numbers. For example: this is a valid British post code: SW1A 1AA. It's slightly non typical in having a letter after the digit in SW1A but it's in London where special rules apply. Here's another more typical one: GL51 0EX.

    You can "validate" British postcodes quite easily with the application of one of three relatively simple regular expressions. However, you haven't really validated, you've just shown it is well formed. I would submit that most errors in entering postcodes will not be caught by checking if they are well formed. British people know what postcodes look like and if they enter one that is not well formed, they are likely to notice before submitting the form. The errors people make will be getting single letters or digits wrong and the only way to detect that is to show them a list of addresses in that postcode and ask them to pick their own out, which you were probably planning to do anyway. There's no point in validating a British postcode with a regex.

    Similarly email addresses. The only way to be sure they've given you the correct email address is to send an email to it and ask them to tell you if they get it. There are regex's of varying complexity for checking email addresses but they're all a waste of time. None of them will tell you that the email address in question belongs to the person in question. Just make sure there's an @ and send a validation email.

  • Arthur (unregistered)

    I think I found the "dude" bit probably the most wrong and offensive part of the code.

  • James (unregistered) in reply to Anonymouse

    More commonly 1+1 to A+1 on the other side. Never really seen your layout in the UK.

Leave a comment on “Javascript Best Practices”

Log In or post as a guest

Replying to comment #:

« Return to Article