Coding Extremes

Coding Extremes

There is a lot of coding extremes that I have noticed as I continue to grow in the enterprise world. It seems like there is always at least 2 ways to solve a given problem in most cases. While I was in school I ended up learning in algorithms that you need to know the cost and benefit of using certain operations. Not knowing these operations can cost later on.

As I have discussed in previous blog posts about Angular's $watch and event based programming, I have noticed that a couple of teams are starting to use events for about everything that is needed. I am pro-events, but I definitely do not agree with using it everywhere at any time that you can.

As a programmer I believe you need to be adaptive and agile to solve the problems presented to you on a daily basis. Which in turn means that you must understand the problem and act accordingly using the tools that you have before you. Granted, the lack of knowledge can be a big factor at play.

The situation would be like this:

If you were assigned the task to cut down the tree and you only knew about a chisel and a screwdriver. I would assume you would pick the chisel. (Please pick the chisel.) What you didn't know was there were also other options available, an axe and a chainsaw. Each tool has their own unique and qualified reasons; there are also drawbacks to each.

The chisel is great for fine details and not really chopping down a tree unless of course the tree was very small.

The axe is great for getting the job done with a little manual labor. While it isn't very accurate and wastes about 2% of the tree in just trying to chop it down and about 10% if you are trying to create logs. It is also good at splitting those logs.

Then there is the chain saw. Its very efficient at cutting things up, but isn't great for splitting things. Not only that but it is gas powered so once it runs out, good luck.

Each one of these has their drawbacks, just like in code. I feel like some are so eager to use event based or Angular's $watch based actions because they are so easy to implement that they are causing more work to be done, rather than considering other things that the language already has built in to help with the issue.

I wanted to explore being able to make objects that announce when properties change. So I created a JSfiddle that does just that. Here is a simple example of using getters and setters in JavaScript. I created a callback function called printer and I called that callback every time the property was changed.

I wanted to do this so I could see if this could be something we could look into. Java is known for building everything from the ground up and JavaScript really isn’t much further from that. I am not sure if this would actually get into our code just because it is kind of messy, but the fact that it can be done proves some merit to it.

We have had a couple of meetings about our current problems with Angular and other inefficiencies on our site. One of the things that was suggested was to try to decouple our dependency on Angular so that way if we choose to pull away from Angular it isn't a huge change. (Regardless it will be a huge change but hopefully we can minimize it a little) I think this might be a little beneficial not just for trying to move away from angular, but I am hoping that it will cause people to think a little more about the code they are writing.

Something I should say too is that I understand that not knowing everything about a particular framework or language can be a barrier to how someone codes. I think the most important thing is to not get offended if someone offers suggestions to your code. It is also important to listen to what is being said and make your own judgment call on what you are writing. If events seem to fit better in this particular case it might actually be better to use them.

For some good information, there is a particular book out there called "JavaScript: The Good Parts". If you haven't read it I would definitely recommend doing so. It is a great book for understanding what are good wholesome practices to follow for JavaScript.