Coding Standards Are a Pain, but I Love It
08 Feb 2018
Pain
Before this class I used the IDE called Eclipse for Java. This was really my only experience with an IDE before. I enjoyed using it because of the environment. It was really user friendly and I enjoyed using it. On Eclipse it was nice that we could format the code to make it look nice, but using IntelliJ with ESLint changed everything. I mean using IntelliJ without ESLint was just like Eclipse, with ESLint it was different. I started doing the practice WODs and felt like my code was right, but I was still getting errors. I did not understand why. I hovered over the errors and noticed the error had to do with the amount of spaces at the end of the document. ESLint did not like to many spaces toward the end of the document. Another error had to do with strings I put in double quotes. ESLint wanted the double quotes to be single quotes. Both of these were not necessarily coding errors, but more so “ESLint errors.” My code would run fine, but according to ESLint my formatting was wrong. This was such a pain to deal with this week, because I did not know how to fix these errors. I thought it was very pointless because as long as the code runs, what would it matter if I had to many spaces or if I didn’t put double quotes somewhere? I did not understand.
Growth
After doing the practice WODs and creating my own practice problems, I started to get use to ESLint. The more practice I got, the less painful it was to do. Using eclipse was nice and being able to format your code made it look nice, but after using ESLint for a little while my opinion has changed on it. I really do enjoy using it now because it challenges me to format my code correctly and make it look as neat as possible. It is very useful because after correcting all the formatting issues, the code is much easier to read. Using ESLint has helped me identify errors without actually having to run my code. For example if I am missing a semicolon or a bracket somewhere, ESLint is able to find that error without me having to run the code. I also tested ESLint to check if it can detect the differences between spaces and tabs. It actually can. I am beginning to really like ESLint because of what it does not only for you, but for people who view your code. With ESLint you can run your code a fewer amount of times because ESLint helps you to identify errors that you might only see after running your program.
Green is the Goal
IntelliJ with the green check mark is nice, but with ESLint it is a different story. Some people may say that it is much worse because it is harder to achieve the green check mark, but others may like it better because of the challenge. I personally enjoy the green check mark with ESLint. The green check mark is the goal and it is much harder to get when using ESLint. You need to correct not only every error that affects your code from being executed, but you also need to check for formatting issues. ESLint really challenges you to look at every single line of code and see what the problem is. Their is usually a red line on the right side of the screen, but when that turns green I find it very rewarding. Whenever I am programming in IntelliJ and using ESLint, the green check is always a goal of mine.
Pain, Pain, Go Away
After spending sometime with ESLint I am finally starting to get the hang of it. I have only spent about a week with it and the first three to four days were very painful because of how frustrating it was. After spending sometime with it each day, the pain has slowly started to go away and I have started to really enjoy it. Each time I program getting the green check mark is not only a goal, but I take it as a challenge. Coding the answer to the problem is one thing, but making it look nice is another challenge. This was the first class I have ever used ESLint in, but I am hoping to continue to use it throughout college and my career as well.