Have you ever had to work on a piece of code and found that it was hard to understand? Maybe the logic was convoluted, the identifiers meaningless, or worse, misleading. You say there was documentation? Was it readable? Did it make sense? Was it up to date with the code? Are you sure? How do you know? This chapter discusses programming by intention, a central idea in XP. It means making your intent clear when you write code.
Test Driven Development: Programming by Intention
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
TDD is a very, very nice idea. At first glance it sounds strange, but it really works quite well. Just get any unit test framework and start to write tests..
A must read is the TDD by example from Kent Beck.
This is a good read, and it seems like the logical thing to do. Nothing is worst when you are looking for a nice algorithm to use such as “quick sort” and the sample code has one letter variable names, even though the logic is pretty straight forward and easy to understand, the code just looks sloppy
Eugenia – Super stuff! Great read. I love when you post these types of articles!
This is 101 for any CS major for the past 20 years. Personally I believe the “intention” should occure when designing the solution and that the code should follow very closely to your origional design. Variable and function names should follow key verbs and nouns found in your solution. Sometimes writting well readable code is the same as writting a good novel.
One thing I have never understood about C/C++, JAVA, etc, is why hasn’t other syntax of code been changed to make it more easily readable and understandable? I am not a good programmer, barely a beginner, but with as long as it takes to learn to program, being put off early by old and cryptic symbols and structures doesn’t seem like a very forward thinking way of doing things. You say writing good code should be like writing a novel? I agree. As I see it, the code itself should read and be writen like a novel with complete words and phrases with direct meaning that is as simple to interpret as a story is. All of the {}, !=, and public void, etc, don’t mean anything to somebody who is new to programming and maybe needlessly difficult for somebody to learn who otherwise might be great at programming. But then again, if it was too easy then everybody could do it. And I know that a lot of it is legacy stuff to support old code, but really, couldn’t an easier way be built on top of what is already there and have it mean the same things? By the way, I am an artist first and a programmer…well not even second, and I wish I could be both, but sometimes a tool just doesn’t fit everybody and it would be nice if there was more choice in how you read and write a program than what is currently available with the “learn it this way because this is how we all have done it for so long” mentality that seems present. I just don’t understand why it isn’t as easy (after learning basic syntax and structure) as it is for me to write this post? Maybe it is and I am just not capable of getting it.
That’s like asking why Mathematics uses obscure symbols as opposed to the English alphabets so that everybody can understand it. The thing is programming is a very abstract discipline, just like Mathematics. Because code is easy to read doesn’t mean you understand it. You need a trained mind to understand code, as it is with other fields.
Writing code that is easy to read, is different from writing clean code. Writing clean code is concerned with designing efficient algorithms and data structures. Writing easy to read code is just a matter of accessibility. If your mind isn’t trained to decipher algorithms and data structures, you could hardly tell the difference between code that is clean and one that looks like a sphagetti ball.
As I see it, the code itself should read and be writen like a novel with complete words and phrases with direct meaning that is as simple to interpret as a story is.
You should learn applescript once. It is basically written with complete words and phrases. It is also a royal pain in the ass to write (still very readable). The problem is that any programming language has a very strict set of syntax and “grammar” rules. English is just way too flexible for programming. So the people of applescript put those extra syntax and grammar rules on english, so it quickly gets unintuitive and annoying to write. Maybe someday you will be able to “program” directly in english, but that won’t happen for the next 5 to 10 years. Getting the semantic meaning out of a text, and then translating it to a bunch of small instructions is a very hard thing to do.
Besides, yes, you should have to study a long time before you are a programmer. No, it’s not about the syntax. The syntax is the easiest part. Design patterns, algorithms, structured programming, creating good unit tests, design, writing proper documentation..
Would you let your 8 year old kid build your house, because they made autocad really easy to use? Then realise that the complexity of a large program is inherently more complex than a building. So why would you let anyone who just finished “Java in 21 days” build it?
But… I already write what I intend to write?
have you tried looking at a cobol program? that may be what you’re looking for
This is new with XP? We called this “self documenting code” back in the 70’s.
Well, duh. The problem is with programmers who aren’t experienced enough to know what they really want…
char buffer[SOME_CONSTANT]; // it’s not this
Forget that evil, confusing C and Java syntax, we should all make a pact right now to do all future programming in Shakespeare:
http://shakespearelang.sourceforge.net
dont jump into c++/java, it seems like you have a passing interest in programming, in which case you would be much better served with something like vb.
there are many, many different languages out there, each one being made for a purpose, or a set of purposes. in the end however, it all boils down to sending the cpu a relatively small range of commands. the “easier” (the real term is “high-level”, it means more english like) requires that much more interpretation to turn it into something the computer understands, which means things like bigger binaries, memory footprints, and lower performance. the lower level (i.e. closer to the actual cpu instructions) the language, the faster/smaller/etc it will be, as there is less interpretation for the compiler to do. even if you made a language that could compile “Make an input box which only accepts numbers”, chances are it would be nowhere near efficient enough for a serious application.
The ultimate way to program would be like the programming of the holodeck on Star trek. However this too is not without its problems. When programming it, you speak in English to the computer, the computer then uses its knowledge and memory of the way you think to create the most expected program. Even then it may have unexpected consequences such as in “Ship in a Bottle” where Moriarty reappears and takes control of the ship. The programmer forgot to specifically say “make a program….. AND don’t give Moriaty root access”.
The point is though, English is very obscure. If you are writing a program closer to English then the computer has to effectively ‘assume’ much more, and this may not be what is expected.
What the “authors” and “creators” fail to mention the project they developed XP method turned out to be COMPLETE and UTTER FAILURE.
If its objective is to SELL books, it does a great job. If its objective is to make projects sucessful, its has a terrible track record.
Us Old Timers, seen fads come in out, seems like it comes with the next group of 5 year programmers. (Typical Life cycle of a developer). Want a methodology that gets things done? Pay me $20k, and Ill tell you how to complete projects
There are a number of languages out there which are emphatically not COBOL, but which are still easier to read for some people (or are seen as having cleaner syntax) than C or Java.
While many people were weaned on C-like syntax, not all of us were, nor do we agree that C is necessarily the best form of notation. You don’t use brackets when you write pseudocode, do you?
I’d personally rather use something like the mainframe CALL macro language I use here (which uses semicolon-terminated block commands and a := assignment operator):
if some_condition or some_other_condition then
Do something;
In a block;
else
Do something else;
In another block;
endif;
than the typical C construct:
if (some_condition || some_other_condition) {
Do Something;
In a block;
} else {
Do something else;
In another block;
}
All the brackets do is make the listing noisier, IMO.
I *hate* the fact that this forum software squeezes out leading spaces (thus destroying my indented examples).
Whatever happened to letting the poster format the text as they please?
Rich, I agree with you. The style I use is a little diffirent but I hate the simple block {}. Simple, powerful, and hell to figure out the logic of many programs with a lot of white-space in them.
Using a bunch of defines I use a COMAL template over my C and C++ code to make it easyier to follow if I come back to it a year later. Example code will look like:
WHILE (condition) DO
block of code
ENDWHILE
IF condition THEN
block of code
ENDIF
IF condition THEN
block of code
ELSE
block of code
ENDIF
LOOP
block of code
UNTIL condition ENDLOOP
I find not only is the code easyier to read, but I don’t lose track what block of code I am reading so often.
ENDIF
since we now have a great refactoring (read also the book of Martin Fawler – refactoring) tool in eclipse (and IDEA has one too). Before making any changes, I refactored if it look not good enough, to be extended. Of course that’s dangerous, that is why I write a Junit testcase before.
Use accepted conventions for accessors and mutators.
I never write any accessor, the tool is doing it for me, I just have to choose the right name for properties.
Use verbs and verb phrases for method names.
I use rename method, objects, properties all the time, changes are done through the whole workspace
Let the Compiler Tell You
CTRL-1 or quick fix in eclipse…if the code do not exist, the compiler will create all stub for You….a must
The key of the problem in existing code is when to start, where to change and how much refactoring can be applied at the same time. The compiler should force us to write junit testcases that can act as a documentation….
Refactoring change my life of developer 😉 and You?
since we now have a great refactoring (read also the book of Martin Fawler – refactoring) tool in eclipse (and IDEA has one too). Before making any changes, I refactored if it look not good enough, to be extended. Of course that’s dangerous, that is why I write a Junit testcase before.
Use accepted conventions for accessors and mutators.
I never write any accessor, the tool is doing it for me, I just have to choose the right name for properties.
Use verbs and verb phrases for method names.
I use rename method, objects, properties all the time, changes are done through the whole workspace
Let the Compiler Tell You
CTRL-1 or quick fix in eclipse…if the code do not exist, the compiler will create all stub for You….a must
The key of the problem in existing code is when to start, where to change and how much refactoring can be applied at the same time. The compiler should force us to write junit testcases that can act as a documentation….
Refactoring change my life of developer 😉 and You?
Using a bunch of defines I use a COMAL template over my C and C++ code to make it easyier to follow if I come back to it a year later
Do us a favor: stop programming in C. Using defines to make a C program look like something else is a sure sign that the programmer doesn’t grok C.
And besides, it’s not necessary:
if (some_condition || some_other_condition)
{
…Do Something;
…In a block;
}
else /* !condition && !some_other_condition */
{
…Do something else;
…In another block;
} /* if (condition, some_other_condition) */
There: by using the concept of comments (I know, a concept so esoteric that only CS PhDs ever hear about it) you get even better results than by using an unadorned ENDIF macro.
When dealing with huge projects where there is a business unit. You need focus and if you are deciding focus and method names at the code level, it is already too late.
As much as people hate UML, it has a time and a place. Focus should be developed at the UML level (use cases, class diagrams, etc…). simply because focus is easier to develop from a higher level. Decisions such as Class names or “Should this method be this large?” should be made before everyone is neck deep in code.
Just my 2 cents.