Tuesday, 1 January 2019

Five Code Practices to Observe Starting From 2019

Hi, guys. 2019 is here. Time for more resolutions!

Back in 2016, I made a short list of things to keep to, and to my chagrin, by mid-2017, I'd slacked off on a couple items. Still, I think I made a good go of it. This time round, my resolutions are all code-based.

1. Spacing

I'm absolutely terrible with this. And in 2019, I'd like to sternly remind myself to keep my code readable by putting in spaces where it's warranted. Sure, it makes not a lick of difference to the compiler or interpreter. But this isn't for the benefit of the machine - it's for the benefit of the poor human eyes that have to read my code.

From crap like this...
var x=(y<obj.average?obj.average+y:(obj.average+y)/(obj.items.length+1));


To this!
var x = (y < obj.average ? obj.average + y : (obj.average + y) / (obj.items.length + 1));


2. Naming Conventions

Another thing I'm really bad at. I tend to name variables either with very vague meanings such as temp or str. Worse, I might even use Hungarian Notation like strTemperature or varX. See, this is pointless. Like in the case of varX, no shit it's a variable, right? Barring constants which I don't use much of, most declared elements are variables.

Here, I resolve to reserve Hungarian Notation only for naming HTML elements, such as txtFullName for a text field or rbOptions for a radio button. It's a habit I carried over from my days using Visual Basic, and it's a hard one to break.

A good practice would be to go from...
String txtName;
Int intId;


... to longer, more meaningful Camel Case names.
String previousTransitionAuditorFullName;
Int previousTransitionAuditorId;


3. Readmes

There's a lot of code in my GitHub account. Unfortunately, not all of it is documented with nicely formattered markdown readme files. I'm making the effort to at least make a note of how the code is written, how it should be run, and so on. Specifically, the idea behind the code.

## Functions

**getAverageStat(statType)**
This function accepts a string, *statType* as a parameter and uses its value to iterate through the corresponding array and determine the average value.

**getTotalStat(statType)**
This function accepts a string, *statType* as a parameter and uses its value to iterate through the corresponding array and determine the total value.


I like to think my code is simple enough to read, but a short note in the repository is responsible coding. No one should have to read through my code without first having an idea of what they're reading. At this point in time, I'm trying to make up for my laxness in the past by documenting repositories as and when I find the time.


4. CSS cross browser

Now, if anyone has any experience with cross-browser CSS, it's using browser prefixes such as -moz- or -webkit-. I tended to do the below, thinking that it didn't really matter, which is wrong. The effect may be less than desired depending on what browse the code is running in, and what styling is being used.

.shootingStar
{
    transition: all 4s ease;
    -webkit-transition: all 4s ease;
    -moz-transition: all 4s ease;
    -ms-transition: all 4s ease;
    -o-transition: all 4s ease;    
}


The correct way is this, and it needs to be hammered home. The standard non-prefixed line has to be last.
.shootingStar
{
    -webkit-transition: all 4s ease;
    -moz-transition: all 4s ease;
    -ms-transition: all 4s ease;
    -o-transition: all 4s ease;
    transition: all 4s ease;
}

Editor's Note: The other prefixes are being included as examples. Some of them are no longer in use for the purposes of the transition property.

5. Doctype declaration

Web pages these days start out like this. Would you believe I sometimes miss out the very first line?!
!DOCTYPE html
<html>
    <head>
        <title>Test Title</title>
    </head>

    <body>
    </body>
</html>


It's easy to blame Sublime Text Editor, which I'm using, for this, since it doesn't include the doctype declaration as part of the shortcuts. However, like any professional, the buck stops with me. Missing the doctype potentially causes a whole host of problems that may cause the page to appear incorrectly. I won't go into those here; suffice to say, every time I catch myself doing this, any code I've written will need to be re-tested.

That's it!

There are a lot more code practices I should be picking up, but these should go a long way. Happy 2019, geeks!

echo strStandardSignOffMessage;
T___T

No comments:

Post a Comment