Tick-the-Code - Probefahrt
Wollen Sie Tick-the-Code ausprobieren? Fahren Sie doch probe. Lernen Sie genug um mehr wissen zu wollen. Die Probefahrt beschreibt genau sechs von insgesamt 24 Regeln. Da sollte man schon einen guten Eindruck gewinnen.
Folgen Sie diese Schritte um erfolgreich probezufahren. Leider sind die Schritte nur auf Englisch.
Preparations | Low-tech approach works for sure. |
---|---|
Print out some code. A thousand physical lines (including empty lines etc.) will do fine. If you know the 'C' programming language, you can print out this Open Source file sample (<20kB). (The file uses Unix-style newlines (LF).) Once you've test-driven (or test-ticked) it, you can compare your results to mine. They should roughly match. Take a bright colored pen (non-black, I mean). Reserve an hour of uninterrupted time. Find a quiet place to retreat to, if your desk is noisy. Protect your quality time and commitment. Silence your mobile phones and pagers, ignore any incoming emails, text messages or any other distractions. Hide from personal interrupts. It's only for an hour. Anybody can be unavailable for an hour. Now you are ready to proceed. |
Recipe for a successful test drive:
Warm the brains up by ticking the code with the warmup rules. Apply the rest of the rules to the code with the pen during the remaining time. Tick until time is up. Enjoy with a pinch of professional pride. |
Start | MAGIC: "Do not hardcode values." |
---|---|
Take the next rule seriously. As checker, do not question any of the rules. No matter how simple the rule feels, check it manually. Even if you could make a script, don't. This simple rule is there to get you to relax. Promise me you're not going to question the rule. Just do it. Promise me! The MAGIC rule says the code is not allowed to include hard-coded values. It means that you, as checker, need to circle (with your bright colored pen) any literal number ( Tick zeros ( Do tick plain numbers as array indices ( Don't tick Don't tick Don't assume you need to do something to the ticks. Don't worry about that yet. You will tick places, which will not be changed. But you will be ticking fast. Once you've gone through the whole code, ticking every violation, count them and write the result on the cover page of your source code (MAGIC: 55). Record the time, too (in minutes). Note any questions or comments that might have arisen during this phase. The rationale behind this rule is that numbers and other values magicked out of thin air are the scourge of software maintenance. In addition, the relationships between the values are often completely missing from the code. That is sure to cause at least wasted time, as a maintenance engineer tries to figure out how to change the code correctly. |
Click for examples of MAGIC ticks |
2nd Step |
ELSE: "An |
---|---|
The second rule is called ELSE. Look for all An The rationale behind this rule is that a forgotten As a general guideline, whenever you're feeling unsure about ticking something, do. The uncertainty means that you must make certain that everything is fine, so you must tick the code. |
Click for examples of ELSE ticks |
3rd Gear |
TAG: "Forbidden: marker comments." |
---|---|
The next rule is called TAG. A tag is normally attached to, for example, a suitcase or a toe. Some comments are like tags, like markers pointing out unfinished business in the code. The rule forbids the use of such comments. Unfinished code poses a threat. There is a real danger of forgetting to finish the unfinished. Sometimes marker comments point to forgotten things, which are always problematic in the digital world, where absolute accuracy is demanded. A marker comment calls you to it to finish the job. The simplest marker comments say Some comments might talk about workarounds for a certain compiler model. We tick such comments, because they might be old and outdated. The time might have come to get rid of such workarounds. |
Click for examples of TAG ticks |
4th Phase |
CLOSURE: "Invalidate pointers and resources after use." |
---|---|
The next rule is called CLOSURE. When you free dynamic memory ( Look for locations where a pointer should be set to This rule applies also to similar situations, i.e. where a pointer, a reference, an object, a handle or anything else is no longer usable. Databases, sockets and file handling contain functional open and close pairs, after which the pointer or handle should be invalidated in one way or another. |
Click for examples of NULL ticks (NULL has since been upgraded to CLOSURE) |
5th Place |
PTHESES: "Parenthesize amply." |
---|---|
Look for places in code which need more parentheses. The rule called PTHESES applies as well to (curly) braces, parentheses and brackets. For example, if a complicated calculation requires you to recall the table of operator precedence in order to understand the order of calculation, it contains too few parentheses. Check especially well macros, they often lack parentheses. The The rationale behind the one-liner /* original */ /* incorrect change */ /* correct change */ if('expression') if('expression') if('expression'){ just_one(); => just_one(); just_one(); yet_another_one(); yet_another_one(); }The C-based languages and Java are vulnerable to this problem unlike Python. The Python programming language doesn't suffer from this because indenting and white spaces are meaningful in it. The rule doesn't say where to place the braces or parentheses. That is a matter of style and there are no wrong answers in matters of style, only various opinions. |
Click for examples of PTHESES ticks |
6th Mile |
CALL: "Call subroutines where feasible." |
---|---|
The rule is called CALL. Your task is to look for blocks of code that could be their own function or method but aren't. You can find them best in large functions or methods. Circle the whole block, which clearly has a purpose and would make a good subroutine. Modularity is along with comments an important theme in Tick-the-Code. In the complete rule set, there are four modularity rules and four comment related rules. Although most big design decisions have been done in the architecture phase (what architecture phase?), the game is not completely lost even in the coding phase. There are ways to make huge functions into smaller, more manageable one-task routines. Little by little, even large systems can be made more maintainable. Assuming we have enough time. That's why you should do this again next week. With small, but regular efforts you can go through a huge system thoroughly and without disruption of your normal duties. |
Click for examples of CALL ticks |
Finish Line | Collect the results and analyse. |
---|---|
Now you've gone through the source code six times. Count the sum of the individual rule violations to get the total number of ticks. Record the total time next to it on the cover page. If you used real code, take the code to whoever maintains it and ask them to take a look at your findings. IMPORTANT: make it clear to them that they are entitled to ignore any tick, even all of them. They don't have to do anything if they don't think it will help. However, there are important principles behind every rule and any tick could point to a possible vulnerability in the source code. A tick is a possible improvement, so they shouldn't just ignore everything without looking. Send your comments and questions to testdrive@tick-the-code.com. If you submit detailed information about your ticking session (tick counts per rule with times, the amount of code, the programming language), I will send you the full set of Tick-the-Code rule cards. Just remember to include your postal address in your email. If you used the sample source code, you can now compare your results with mine on the right. They should roughly match. If this test drive made you interested in learning more, ask for an offer on a Tick-the-Code training at your company or in your city. |
Here are my results on the sample file.
(*) The NULL rule has since been upgraded to CLOSURE. (**) I checked the rule ELSE last, unlike the instructions state. |
Zuletzt aktualisiert: 16.8.09.