Often in any development there is a need to write code, about which it is known in advance that it:

  1. Extremely flexible. Or..
  2. May cause bugs, problems in the future. Or..
  3. We do not read at all.

Or such a code is inherited, and I want to mark the places that need to be corrected later. This code is called a crutch in Russian. Unfortunately on the English-language sites it is difficult to find information about this, since they have the term "crutch" - absent in principle. It is recommended to translate as "kludge" - but this is not often understood.

The question is how to mark crutches in the code with comments, so that it is easy to make a list of all the crutches in the project, and it is highly desirable that their visibility in the IDE could even be prioritized? I am more interested in PhpStorm, but others will be interested to learn about their IDE.

PS
Of course there is a special tag in the TODO comments, but I would like to present the crutches and TODO separately from each other, all the same, they are very different in essence. Therefore, some agree on special comments like:

 /* TRASHCODE {why below code is bad} */ ... /* TRASHCODE end*/ 

Then it is easy to search for the code, but in this case there is no IDE help in viewing crutches.

  • Ctrl + A, Del? :) - Nick Volynkin

3 answers 3

I would like to present the crutches and todo separately

First, all decent IDEs except TODO understand FIXME out of the box.

but IDE doesn’t help on crutches

Secondly, all decent IDE :) can add custom task tags.

PhpStorm (and any other Djetbrain):

enter image description here

Eclipse (you can customize even for each language / project):

enter image description here

for FIXME and TODO - can we mark the end? That is, select with the help of comments block.

As far as I understand, no, only one line with a keyword is tracked everywhere. The maximum that you can - click on it in the appropriate tab and go to this place in the source.

CLion :

enter image description here

In tab:

enter image description here

Eclipse :

enter image description here

In tab:

enter image description here

  • And do not tell me, for FIXME and TODO - can we mark the end? That is, select with the help of comments block. - Goncharov Alexander
  • one
    @GoncharovAleksandr, added in response. - PinkTux
  • @PinkTux date not used in the tag? And if you are not one developer, then the name: TODO (Vasya-1212172221), then the stamp is then used as the fix ID - Hellseher

Ahahaha ... There is nothing more permanent than a temporary solution.

If you can’t write concise and flexible code for a specific task, then you have problems with architecture design and you should pull up your skills, such problems for novice developers due to lack of experience. Remember that one crutch requires a pile of new crutches, expansion of the system and its functionality, as well as making changes will be difficult.

You are a little wrong about the lack of a crutch in English, it is often called kludge or workaround

Pieces of code that need to be fixed are often noted with the help of FIXME , which is supported by many editors and PHPSTORM too, it is noted in TODO. FIXME is placed directly in front of the problematic participant and may contain a description in which lines the code contains problems and that there are no limits to the problems that need to be fixed.

 FIXME: строки 38-120 имеют низкую абстракцию. 

Experience

I can say that I and colleagues, we rarely mark crutches. Often, they immediately rewrite without any marks at the time of a new task or searching for an error (the class has already shot several times, even after correction), because all these marks with a lack of time turn into permanent ones . Crutches are naturally rewritten without fanaticism , in order to save business money for further product development and support.

If the team supports striving for a high level of abstraction and adhering to the rules for the number of lines in a class, refactoring some kind of curved code does not take much time , but if inherited, then you need to determine the level of refactoring depending on the time provided for the task.

PS Avoid unnecessary paradigms: crutches , inkstalation and polycostilism , write a beautiful code by attaching to it at least a minute of design.

  • IMHO, TODO, and FIXME are perfectly normal with the practice of frequent commits. Of course, they should get into the push as little as possible, but in the process of their work there are quite a few, what is so bad about it? This is nothing more than another tool for navigating the "raw" source. - PinkTux
  • > If you can’t write concise and flexible code for a specific task, then you have problems with designing architecture and you should pull up your skills, such problems for novice developers due to lack of experience. - Goncharov Alexander
  • 3
    @Firepro Well, a bad start to the answer, what a pride, a) Who does not understand why crutches are necessary - he did not go to the front line. Because the customer has secured something, because there is not enough money at all, because PM is not in principle, because the project is burning, and something needs to be done urgently, because someone wants to make money. - Goncharov Alexander
  • @Firepro and by the way does not go around them in everyday life kludge, at least familiar foreigners were perplexed about what I mean by that. About workaround not heard. - Goncharov Alexander
  • @GoncharovAleksandr more often use workaround ( ru.wikipedia.org/wiki/… ) and it is often found in articles. I can understand the crutch from the lack of time or bypassing a temporary bug in a third-party library, or when the whole project is already in crutches, and writing an adequate solution no longer makes (expensive), but everything else is connected with a lack of experience. Although even when time is short (not extremely short and this is a fatal bug), it is still necessary to build on the solutions already implemented and this will reduce the crutch. - Firepro

Php

 #region FIXME Bug text ... #endregion 

Javascript

 //region FIXME Bug text ... //endregion