Abstractions are often good and even neccessary. But, it’s easy to misjudge their costs. Even “zero cost abstractions” such as C++ advertises have hidden costs. Let’s explore one involving multipe inheritance and null pointers.

When explaining FSMs, people often focus on theory or a particular, usually “advanced” approach of writing them. Experience shows that the “low level” code organization of FSMs greatly influences their quality.

C++ provides dynamic dispatch via virtual functions. Most common implementation uses “v-tables”, with each object having a pointer to said v-table. In some cases, this is undesireable. There are other reasons to avoid virtual functions and here we present a low-effort way of doing so.

Exceptions should be application specific, rather than generic and code/library specific. They should be caught at the place where there is enough information to handle them properly and where the handling takes the least amount of effort (code).

Often, a task you’re working on has some identificator from some “ticketing” system, like currently popular JIRA. Usually it’s a short mnemonic followed by a number, something like: MSP-5443. It’s nice to put this ID in stuff. For example, if you put it in your VCS comments (on commit/check-in), JIRA can link VCS commit to the ticket. But, in source code, it can be distracting, become outdated and, basically, is a maintenance nightmare.

It’s hard to explain what is “real time programming” and how to do it. Instead, we’ll show some “everyday” code that is not “real time” and how to go about making it “real time”. As we’ll see, no, it’s not enough just to avoid dynamic memory allocation - it’s not even required.

Coverage is a useful metric of testing, but, high coverage is not the goal. Code can have 100% coverage and still have bugs. For example, if some code is missing and thus software doesn’t do what it’s supposed to do.

Just because you’re writing in C, doesn’t mean you have to write bad/complex/long code. C is not the enemy, you can write bad code in any language, and you can write good/simple/short code in C. We’ll show how some 20 lines of C string handling code can be reduced two one or two lines.

Designing, implementing and documenting corner cases is hard because it’s boring. So, we tend to think that the general description fits the corner case. Even if it doesn’t, it’s “close enough” and it doesn’t happen too often and, as long as it doesn’t crash, it’s OK. But, this is software, it has no soul and plays no favorites to any values and/or (corner) cases. Corner case should be “just another case”.

Осмишљавање, прављење и описивање граничних случајева је тешко јер није “забавно”. Углавном подразумевамо да је неки општи опис довољно добар за граничне случајеве. Па, ако баш и није, то је, бре, гранични случај, ретко се дешава и ако се ништа не “спуцава”, у реду је. Али, овде причамо о програмској подршци, која нема душу и нема миљенике међу вредностима и (граничним случајевима). Дакле, сваки гранични случај би требало да буде “просто још један случај”.

То што програмирате у Ц-у, не значи да морате да пишете лош/сложен/дугачак код. Ц није непријатељ, јер лош код може да се пише у било ком језику а добар/једноставан/кратак код може да се пише и у Ц-у. Показаћемо како се 20ак редова Ц кода који се бави нискама може да сведе на један до два реда.

Покривеност кода је корисна метрика тестирања, али, висока покривеност није циљ. Код може да има 100% покривености, па да ипак има буба. Рецимо, ако неки код недостаје, онда програм не ради оно што би требало да ради.

Тешко је објаснити шта је то “програмирање у реалном времену” и како га извести. Уместо објашњавања, даћемо пример обичног кода и како да се исти “претвори” у код за рад у реалном времену. Како ћемо да видимо, не, није довољно просто избегавати динамичко заузимање меморије - штавише, то није неопходно.

Често, задатак на коме се ради је дефинисан-описан у неком систему за евиденцију буба (у време писања ових редова, ЈИРА је била популарна). Сваки задатак (буба, “тикет”) има неки идентификатор. Углавном, ради се о мнемонику после кога следи број, попут: МСП-5443. Симпатично је и корисно да се овај ознака упише “на погодно место”. Рецимо, у напомени у систему за контролу верзија (при стављању у СКВ), што омогућава да ЈИРА повеже бубу са одговарајућом изменом у СКВ. Али, у изворном коду, скреће пажњу, лако “забуђа” и, једном речју, представља мору за одржавање.