Why it pays to invest some time learning the syntax and terminology of a language

Syntax is boring. Absolutely boring. So is theory and terminology. But neither is trivial. And neither is superfluous. Not if you want to get up to speed as quickly as possible.

Syntax differs from language to language. Everybody accepts that. Not everybody is as aware that while the concepts of object orientation are the same across object oriented languages, the words used to describe their implementation may differ as well.

And that is a big part of what makes compiler error messages read like the prose from an obscure poet in an extra-terrestrial language.

Mystic error message often become a lot clearer with even the flimsiest of knowledge of a language’s syntax and terminology.

Take this bit of C# code

    namespace TestProject.TestingAbstractBaseClasses
    {
        [TestClass]
        public class Bashful_Tests
        {
            private class Bashful_Tester : Bashful
            {
            }

            private Bashful _Bashful;
    
            protected void ArrangeBashfulInstance
            {
                _Bashful = new Bashful_Tester();
            }
    
            [TestMethod]
            public void DoSomethingUseful_WhenPassedNull_ShouldUseValueProvidedByDescendant()
            {
            }
        }
    }

It gives a “A get or set accessor expected” error.

At the time this had me completely mystified. “Accessor” was an unfamiliar term. The “get” or “set” qualification hinted at properties. In Delphi (the language I use at work) the methods that provide the “get” and “set” behavior for a property are referred to simply as “getters” and “setters”.

Ok, so it has to do with properties.

In Delphi property declarations look like

    property StraightFieldProperty: TypeOfTheProperty read FSomeProperty write FSomeProperty;
    property GetSetMethodProperty: TypeOfTheProperty read GetSomeProperty write SetSomeProperty;

The StraighFieldProperty is syntactic sugar for accessing the FSomeProperty instance field. The GetSetMethodProperty is a bit more than syntactic sugar and specifies that the value is returned by GetSomeProperty and set by SetSomeProperty. In other words: GetSomeProperty and SetSomeProperty are the getter and setter method for GetSomeProperty.

And I wasn’t declaring any properties! I was just declaring and implementing a method. No property even remotely in sight!

Or was I?

To my mind I wasn’t doing anything remotely related to properties in the C# code. Yet the error message was telling me that the C# compiler thought I was.

What the …?

Ego deflated, I had to resort to googling the error message. Judging by the number of search results, I am not the only one stumped by this one (which re-inflated my ego a little).

This is the fixed code

namespace TestProject.TestingAbstractBaseClasses
    {
        [TestClass]
        public class Bashful_Tests
        {
            private class Bashful_Tester : Bashful
            {
            }
    
            private Bashful _Bashful;
    
            protected void ArrangeBashfulInstance()
            {
                _Bashful = new Bashful_Tester();
            }
    
            [TestMethod]
            public void DoSomethingUseful_WhenPassedNull_ShouldUseValueProvidedByDescendant()
            {
            }
        }
    }

Did you spot the difference? [1]

Had I had a clear understanding of how to declare properties in C#, my error would have been clear instantly. But I didn’t. And wasted time. Admittedly not much this time, but this was not the only one and it adds up quickly.

Google is my friend, but switching to a browser window, entering a search, clicking on and reading through search results, judging the answer… That whole shebang costs more than just the time it takes to find the answer you need.

It catapults you out of flow.

So why does it pay to take the time to familiarize yourself with the syntax and terminology that is idiomatic to that language?

Because it will save you oodles of time and a mountain of frustration!

And the best way to consolidate your new found knowledge?

Put together a cheat sheet with the syntax of the main language constructs as well as a list of mystic error messages including their causes and solutions.

Especially the solutions to those error messages!

If someone would have given me a dime for every time I sighed in exasperation “I have seen that message before, I know I have.” and not being able to recollect the way to get rid of it, I would be able to retire by now. Well, ok, probably not, but you know what I mean.

Enjoy!

What compiler error messages have had you stumped and turning to your colleagues or Google?
I’d love hearing from you by email or in the comments.

Notes

[1] It is the parenthesis pair after ArrangeBashfulInstance.

Posted in Software Development
Tags: , , , , ,
One comment on “Why it pays to invest some time learning the syntax and terminology of a language
  1. The curse of Delphi programmers not using parenthesis after parameterless methods.

    It’s one thing I learned about switching languages: use parenthesis idioms that fit multiple languages:

    parenthesis around the boolean expressions in if/while/… constructs
    parenthesis at each parameterless method declaration and call

    It helps a lot using ReSharper or CodeRush in Visual Studio and ModelMaker Code Explorer in Delphi: they get these details right.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Show Buttons
Hide Buttons