#Multipurpose room written inshort hand code#
Don't write code like that - it might make it more art than product, but this is rarely a good thing. Try reading Dostojewski if you want a comparison to the real world - I got lost on a page with 14 Russian names, 4 of which were pseudonyms. If you need to use a sketchpad to keep up with the flow of logic, then your code needs some work. If you can read line by line and understand what is going on, well done.
Having spent some time debugging Korean and Slovenian code, I can assure you it is not much fun for a non-native speaker. Programming languages are in English, so why not keep this as a logical step for the rest of your code. It is very informative for some, but seems like extra overhead to others - it is really up to you whether you use it or not. An object called member would be oMember and a Boolean called isLegal would be bIsLegal. Hungarian notation is a good variable naming scheme to adopt (there are other naming schemes to consider), the advantage being that you know what something is supposed to be and not just what it is.įor example, if you have a variable called familyName and it is supposed to be a string, you would write it as sFamilyName in “Hungarian”. A function called isLegalDrinkingAge() makes more sense than isOverEighteen() as the legal drinking age varies from country to country, and there are other things than drinking to consider that are limited by age. One trap to avoid is marrying values and functionality in names.
None of these make much sense - good variable and function names should be easy to understand and tell you what is going on - not more and not less. This is a no-brainer but it is scary how often you will come across variables like x1, fe2 or xbqne in JavaScript, or - on the other end of the spectrum - variable names like incrementorForMainLoopWhichSpansFromTenToTwenty or createNewMemberIfAgeOverTwentyOneAndMoonIsFull. However, I have found that following these principles has made me a more effective developer and allowed other developers to build upon my work more easily.Ĭall things by their name - easy, short and readable variable and function names I am sure you will find things to disagree with, and that is a good thing - you should question what you read, and strive to find better solutions. Take the advice below to heart and keep it in a part of your brain that has a quick access route so you can apply it without thinking about it. So I’ve decided to make it easier for you by creating this article, which is a compilation of best practices and good advice I’ve amassed over the years, much of it learnt the hard way (experimentation and suchlike). However, looking around the web and getting code handed over to me from other developers for years has taught me that common sense is actually quite a rarity in live code on the web, and the “sensible and logical thing to do” gets pushed far down the priority list once you are in the middle of a project, and the deadline is looming.
To a number of you, what you are about to read will appear to be very obvious and just the sensible thing to do. Writing a best practice article is quite a tricky business. 16 Add functionality with JavaScript, don’t create too much content.10 Allow for configuration and translation.7 Use shortcut notation when it makes sense.5 Comment as much as needed but not more.2 Call things by their name - easy, short and readable variable and function names.
0 kommentar(er)
