Ever seen a class and started thinking the only way to understand what it does is by rewriting (or deleting everything). This feeling has really no basis but it's more of a feeling that something just doesn't seem right. The truth is that we all find it easier to read code written by us than by others. Despite that, there is highly readable code and less readable. There are thousands of articles on code readability, clean, structured (newspaper metaphor), craftsmanship and other terms describing characteristics for code writing. But what characterizes a professional programmer? Extensive knowledge? Ability to lead a technology project? Or rather the mere definition of his directors that that developer reliability is of fire and forget. I think that what characterizes a professional developer is the ability to share, understand, expand and modify their work by other members of the development team.
I would like to coin another term - team coding. The way I see it, programming for a readable and clean code base is far superior to maximum efficiency. Team usually conform to some standard or a way of writing code (usually, a complete mess). Since most developers will simply follow the same style they encounter (explained partially by the Broken Window Theory), the style shouldn't be left undefined. Defining coding standards along with formatting rules, coding style and even how to write issues and comments might ease the development process. Here's a real life example: In a recent lecture I presented my development group how a unit test is structured. I explained that mocked members should have the mock prefix (e.g. mockFoo) and usually the class under test is called tested (or classUnderTest). As times went by, unit tests were added to the code base (thank God!) and additional test cases were added to existing ones. I sat for pair programming with another developer. When we reached to the part of adding a new test case she immediately wrote a case without even looking at the the field deceleration, simply by following the coding conventions for tests. That's team coding! Another team member was able to continue another developer work without too much hassle.
Style rules and automatic formatting actions reduced merge scope to conflicting statements only and developers can focus on what to write instead of where should a bracket should go. Modern IDEs (I'm currently working with Spring Tool Suite - an Eclipse distribution by SpringSource) support save actions that can configured to apply shared style rules. Oracle publishes Java Coding Conventions that will suite most teams. In my development group we took them as a basis and changed it a bit to better fit our code structure. The process of setting coding standards was long and had it share of discontent but these guidelines (style, standards, best practices, etc.) made our code base look (and feel) much more organized.
Some might argue that we reached the days where coding standards are not needed. I even heard an argument that every programer codes differently, and setting such conventions will damage their individualism. To that I have only one thing to say: Software development is like Communism - either you work as a team for the good of the company or you're sent to work on some BS assignment cleaning code. If Communism is not your thing and you're more into French stuff the idea is the same as The Three Musketeers :-)
I would like to coin another term - team coding. The way I see it, programming for a readable and clean code base is far superior to maximum efficiency. Team usually conform to some standard or a way of writing code (usually, a complete mess). Since most developers will simply follow the same style they encounter (explained partially by the Broken Window Theory), the style shouldn't be left undefined. Defining coding standards along with formatting rules, coding style and even how to write issues and comments might ease the development process. Here's a real life example: In a recent lecture I presented my development group how a unit test is structured. I explained that mocked members should have the mock prefix (e.g. mockFoo) and usually the class under test is called tested (or classUnderTest). As times went by, unit tests were added to the code base (thank God!) and additional test cases were added to existing ones. I sat for pair programming with another developer. When we reached to the part of adding a new test case she immediately wrote a case without even looking at the the field deceleration, simply by following the coding conventions for tests. That's team coding! Another team member was able to continue another developer work without too much hassle.
Style rules and automatic formatting actions reduced merge scope to conflicting statements only and developers can focus on what to write instead of where should a bracket should go. Modern IDEs (I'm currently working with Spring Tool Suite - an Eclipse distribution by SpringSource) support save actions that can configured to apply shared style rules. Oracle publishes Java Coding Conventions that will suite most teams. In my development group we took them as a basis and changed it a bit to better fit our code structure. The process of setting coding standards was long and had it share of discontent but these guidelines (style, standards, best practices, etc.) made our code base look (and feel) much more organized.
Some might argue that we reached the days where coding standards are not needed. I even heard an argument that every programer codes differently, and setting such conventions will damage their individualism. To that I have only one thing to say: Software development is like Communism - either you work as a team for the good of the company or you're sent to work on some BS assignment cleaning code. If Communism is not your thing and you're more into French stuff the idea is the same as The Three Musketeers :-)
No comments:
Post a Comment