How to document in code a hack, Hotfix and any potentially problematic outline situation

Asked

Viewed 130 times

6

Hacks, emergency fixes and any potentially problematic contouring situation are a necessary evil. Although it can be considered personal opinion, when working in a team, a minimum of care is assumed to alert colleagues, or the programmer himself, in the future.

My question is: what is the minimum standard that would be expected from a programmer to document such code in the code itself, assuming that it works on a small team of 2 to 7 developers.

Something I personally do is in a comment, next to where the problem occurs and not in the function header, by something like

// @todo mensagem explicativa, proporcional a complexidade (nicknamedoprogrmador 2014-02-05 14:23)

In my case @todo can be exchanged for @hotfix, but it is always something common to use.

Although this question can be answered with your personal opinion, if there are references to expert recommendations or specific methodologies it will be more welcome for all.

  • 1

    In my view this depends very much on the IDE used. Visual Studio, for example, marks comments as //TODO: and //HACK: on a Toolbox for easy identification and localization. Plugins like Resharper also color and emphasize such lines. Other plugins allow inserting such notifications in check-ins and code Reviews, so that they are always visible (after all, a WHOLE: as comment is as comment eternally)

  • 1

    +1 because I found a very interesting question! The solution of putting a comment is appropriate and I think @Jcködel should elaborate the suggestion of Visual Studio mark the lines and create a response.

  • Anyway, if I may suggest a little outside the scope of the question, more important than the comment in the code is the annotation of the hack in some version or workflow control tool. As more tasks accumulate, it is very easy to forget the "temporary changes" and they end up becoming fixed...

  • Problem of documenting outside the code a code problem is that in general programmers do not read documentation. The scope of my question is with the focus on be the really minimum and essential that anyone should do. Plus most programmers already use version control, so it’s easy to grab file history. Anyway, staff is free to put suggestions beyond what to put in the source code.

  • @Emersonrochaluiz The scope of your question is very clear. And in fact, in my additional suggestion I point out that this is something out of scope. I merely mentioned that, however well documented "Hotfix" is in the code (and I am totally in favor of it!), someone has to ensure that it is eventually redone properly. Programmers may be on other tasks and project managers do not usually open code. Thus, if a change is temporary and needs to be rethought, it also needs a persistent notification outside the code context.

1 answer

4


In my view this depends very much on the IDE used. Visual Studio, for example, marks comments as //TODO: and //HACK: on a Toolbox for easy identification and localization. Plugins like Resharper also color and emphasize such lines. Other plugins allow inserting such notifications in check-ins and code Reviews, so that they are always visible (after all, a WHOLE: as comment is as comment eternally)

Example of the VS tool:

inserir a descrição da imagem aqui

  • Since you still haven’t had any other answers, I’ll wait a little longer before approving

Browser other questions tagged

You are not signed in. Login or sign up in order to post.