Wednesday 13 November 2013
Your compiler is your friend
Today, I spent a small amount of time helping a developer solve a problem.
That may be how I start a lot of my posts for a while since I am working with some smart chaps who are learning to be better devs. The thing about learning to be a better developer is that you learn it from writing a helluva lot of code and from working with old grey haired devs like me.
Ok, I don't have grey hair but I do this wise Gandalf voice that really deserves some grey hair.
When I started developing, a compiler wasn't much without a linker. We spoke of lint and didn't mean the stuff left in driers. We had pet dinosaurs.
One thing that understanding the parts that come together to be the Build that we all speak of now is that we learnt to listen to what each part was telling us. No, no, I don't want you to go out and conduct some native American dreaming ceremony but I do want you to listen to your compiler warnings.
In today's adventure, I paired with a developer who was having issues adding a set of XSD schemas to a .NET schema collection. The thing is that this class was deprecated after .NET 2.0 and the reader feeding it was also of the past.
The compiler told us so.
The thing is that although many developers are warned over and over again that they are using an old API function and to use X instead, they persist. They ignore that and many other warnings. This however is the most common one I see outside of warnings about variables being initialised but not used.
Your compiler is telling you this for a reason. It isn't because it has had a slow day or it is having a grumpy moment. No, it consistently warns you that there is a better way to do things now and even suggests how you should attempt this.
So, we solved our issue today by listening to the warnings and using the latest and greatest (be it 3 years old) and all was well.
Yes, we have evolved as a profession to obey our build errors and not check in a broken build to avoid the hisses and boos of our colleagues. Now we must grow to listen to the warnings. They are not wasted cigarette lighters at a Pink Floyd concert. They are not a gasp of exclamation in a sea of squealing teenage girls at a boy band concert. They are not platform high heels at a Kylie Minogue concert. No.
To be a better developer, you will listen to the advice you get from your build, your static code analysis and your IDE refactoring suggestions. You will do it because it will make your code better and more up to date. You will do it because it will stop the bad things happening that happened to those before you. You will do it because it will stop my soul from hurting.
Be it Visual Studio or IntelliSilly, your IDE is your friend. Your compiler warns that there be dragons and you must listen.
Apple started a user experience trend many iOSes ago when it accepted Settings changes and did not ask for confirmation. Once the chang...
Recently I was asked to disable the submit event being triggered when the enter key is hit in a textbox input. This is for an ASP.NET MVC ap...
Having used ASP.NET MVC since it was in Beta in 2008, I am asked every time I mention those extra three letters why you'd bother moving ...
Photo by markknol used under the flickr Creative Commons license I've recently started using Google Analytics for my blogs. Yes, I'...