4 ms·

Well, maybe a good way to avoid this is to have the compiler email the manager rather than printing a warning.

by d--b 9y ago

fazkan 9y ago
or summon nasal daemons http://www.catb.org/jargon/html/N/nasal-demons.html http://www.catb.org/jargon/html/N/nasal-demons.html
- bitwize 9y ago
  "Nasal Scott Nudds" was popular in the late nineties.
  - fao_ 9y ago
    Who was Scott Nudds?
    - bitwize 9y ago
      Legendary troll on comp.lang.c and elsewhere. His catchphrases include "Unix is dying, and the world is better for it." And "I, on the other hand, prefer honesty."
skgoa 9y ago
You might be joking, but I know at least one major electronics company where the automated machine tools will send text messages to the plant manager in ever increasing frequency, when scheduled maintenance is coming up. Because otherwise those plant managers wouldn't allow the required downtime.
wyldfire 9y ago
In all seriousness, management who takes things like static analysis results seriously is a valuable asset. We should consider teams that have management like this as superior to the ones who don't. They clearly value foresight and planning and will probably be less likely to host a chaotic/careless work environment.
- TeMPOraL 9y ago
  Except when they take it too seriously. At my $dayjob, I have a problem with a cow-orker with a position slightly superior to mine ("first among equals", former team lead of the group of projects to which I'm assigned) taking results of static analysis too seriously - to the level of cargo culting. When bored, he'd introduce "fixes" to reduce number of issues reported by SonarQube - "fixes" I have to revert every now and then, because they reduce quality of the code (sometimes also introducing bugs through carelesness), all to optimize the Sonar metric. To be clear: tools are fine. It's people that are the problem (as usual).
  - btschaegg 9y ago
    It also strongly depends on the type of tool you use. If by "static analysis" you mean "Clang screams at me if I'm juggling with razor blades", the results mostly seem to be rather useful. But I've yet to see one of those code-visualizing tools based on metrics that convinces me. The results I've seen so far are either obvious ("I already knew that, thanks") or inconclusive and hard to interpret. So, to me those tools seem to be more of a way to try and convince your manager that you should be given time for refactorings than actual utilities. I've been wondering if there could be a benefit in analyzing the commit history of a project instead so that one could somehow at least visualize obvious problem areas ("every third bugfix has to touch this piece of code, so we should really have a proper cleanup there...").
    - joevandyk 9y ago
      A "churn" metric would show if a given piece of code is getting changed frequently. That can identify hot spots in the code.

Well, maybe a good way to avoid this is to have the compiler email the manager rather than printing a warning.

by d--b 9y ago

Well, maybe a good way to avoid this is to have the compiler email the manager rather than printing a warning.

or summon nasal daemons http://www.catb.org/jargon/html/N/nasal-demons.html http://www.catb.org/jargon/html/N/nasal-demons.html

bitwize 9y ago
"Nasal Scott Nudds" was popular in the late nineties.
- fao_ 9y ago
  Who was Scott Nudds?
  - bitwize 9y ago
    Legendary troll on comp.lang.c and elsewhere. His catchphrases include "Unix is dying, and the world is better for it." And "I, on the other hand, prefer honesty."

skgoa 9y ago

You might be joking, but I know at least one major electronics company where the automated machine tools will send text messages to the plant manager in ever increasing frequency, when scheduled maintenance is coming up. Because otherwise those plant managers wouldn't allow the required downtime.

wyldfire 9y ago

In all seriousness, management who takes things like static analysis results seriously is a valuable asset. We should consider teams that have management like this as superior to the ones who don't. They clearly value foresight and planning and will probably be less likely to host a chaotic/careless work environment.

TeMPOraL 9y ago
Except when they take it too seriously. At my $dayjob, I have a problem with a cow-orker with a position slightly superior to mine ("first among equals", former team lead of the group of projects to which I'm assigned) taking results of static analysis too seriously - to the level of cargo culting. When bored, he'd introduce "fixes" to reduce number of issues reported by SonarQube - "fixes" I have to revert every now and then, because they reduce quality of the code (sometimes also introducing bugs through carelesness), all to optimize the Sonar metric. To be clear: tools are fine. It's people that are the problem (as usual).
- btschaegg 9y ago
  It also strongly depends on the type of tool you use. If by "static analysis" you mean "Clang screams at me if I'm juggling with razor blades", the results mostly seem to be rather useful. But I've yet to see one of those code-visualizing tools based on metrics that convinces me. The results I've seen so far are either obvious ("I already knew that, thanks") or inconclusive and hard to interpret. So, to me those tools seem to be more of a way to try and convince your manager that you should be given time for refactorings than actual utilities. I've been wondering if there could be a benefit in analyzing the commit history of a project instead so that one could somehow at least visualize obvious problem areas ("every third bugfix has to touch this piece of code, so we should really have a proper cleanup there...").
  - joevandyk 9y ago
    A "churn" metric would show if a given piece of code is getting changed frequently. That can identify hot spots in the code.