The Lazy Programmer

I would like to introduce myself as a lazy programmer.

I don’t like to type a few lines and remove those again again until it works.

- Yeah I prefer to write codes only when I’m sure that’s what I want to write. For this I do one of two things. I write down my thoughts on a piece of paper or something similar. Or I just think about in my head. Once I’m sure that this is what I want only then I write the code. Before writing a single class I think what’s its purpose or what dependencies will it have or what other classes might be dependent on it. Or Is this class even necessary ? What properties the class should have. Why is this property even necessary ? Do I want others to know about this property ? No? then make it private . Does this property need to be modified? No? make it read only. Same goes for functions. If I think any function that doesn’t require external access I’d make those private. How this helps you might ask? Since I’m lazy I don’t wanna remember how this class works. I make the class name obvious. Make sure the public functions/property names are self explanatory. So that I can totally forget how this class works. When I need I just create an instance and see what functions it offers.

Function and Property names.

- Since I’m lazy I don’t wanna come back and rename the A() function or BB_ variable or property that I wrote down in a hurry later. Because Coding in a hurry would just add more work time later. Because If I ever have to come back to the code(Which I always have to) I’ll be at a loss. Because the names of the function or property will make no sense at all. So To save later work I’d rather write down the names properly now which might cost me 1 extra second now that will save 1 minute later.

Reusable Functions

-Every time I write a function I ask myself what possible usages it can have. Because right now my function my just do one task but it might need to do bit more later. Suppose I’m writing a function that inserts a data into a file.Lets call it WriteToFile(). Now I ask myself should it be a void function or it should return a boolean of it’s success. It’d be easier to just write a void method and just be done with it. But then it hit my mind that since it’s a write to a file operation it could throw some exceptions like not being able to open or write file due to access restrictions. But my function here wouldn’t know that.It’s just going to throw an exception. Which I’ll have to find later and tear my hair. So instead of solving that later let’s fix it now. I’ll make this a boolean function and put a try catch block if any exception occurs I’d return false otherwise the file has been written successfully so I can return true. If I want to go one step further I’d also put an out parameter(C#) to the function to send the exception as well. So how does it help? I can use that WriteToFile() Like before but now I have one more option available to me. I can check if the function has successfully written the file or not. And show the users appropriate messages. I couldn’t do that before if I had a void function. In case there was an exception the application would just crash. From my experience It’s always good to avoid void functions. If you are writing a void function you are just going to add more work later.

Stick to one convention

-I always stick to one convention. I’m not talking about naming conventions only. I’m talking about everything we do in a code. For example I always write properties at the top of the class. If the class has way too many properties I group them into sections and comment them out so the groups stand out . Why? This helps me find those later. Since I’m lazy I don’t wanna waste my time scrolling up and down. After I have written down all the properties I go on defining the methods. I make sure the methods are grouped together as well so that similar methods are near one another and In case I ever need to go through it, it should be near my hand.

Being lazy at coding doesn’t mean not writing code. It means Write your code properly and efficiently so that you don’t have to waste your time over old codes.

A STITCH IN TIME SAVES NINE