robinsedlaczek/forcefeedbackprogramming

forcefeedbackprogramming's Issues

Mehrere Einfärbungen

Es soll nicht nur binär abhängig von einer Zeilenzahl eingefärbt werden, sondern in mehreren Stufen, z.B.

• ab 10 Zeilen gelber Hintergrund,
• ab 20 Zeilen oranger Hintergrund,
• ab 40 Zeilen violetter Hintergrund
  usw.

Für jede Einfärbung ist ein Eintrag in der Konfigurationsdatei zu hinterlegen:

{
  colorings: [
    { lines: 10, color="#FFFF00", transparency=0.25 },
    { lines: 20, color="#FF4500", transparency=0.25 },
    { lines: 40, color="#FF00FF", transparency=0.25 }
  ]
}

RGB-Farben mit Hex-Werten: http://www.farb-tabelle.de/de/farbtabelle.htm

Zwischen den Farben wird gewechselt, sobald sich die Zeilenzahl in einer Methode verändert.

Einfärbungsbreite schwankt

Beim Scrollen verändert sich die Breite des Einfärbungsrechtecks einer Methode, je nach dem wie lang die längste sichtbare Zeile ist.

Stattdessen sollte das Einfärbungsrechteck immer gleich breit sein und der längsten Zeile einer Methode entsprechen.

Optional: Einfache Leerzeilen und geschweifte Klammern optional nicht mitzählen

Mein Vorschlag wäre, dass (optional) einfache Leerzeilen nicht mitgezählt werden. Diese tragen meiner Meinung nach u. U. zur Lesbarkeit bei und sollten daher nicht "abgestraft" werden. Doppelte/mehrfache Leerzeilen könnten schon gewertet werden.

Gleicher Vorschlag für die geschweiften Klammern. In meinen Augen sieht ein IF/FOR-Block mit geschweiften Klammern in einer Extra-Zeile übersichtlicher aus. Denselben Code in eine Zeile quetschen kann ja nicht das Ziel sein... Aber da gibt es sicher auch andere Meinungen, die in sich ebenfalls schlüssig sind - vieles ist einfach Gewohnheit. Daher wäre das als einstellbare Option ein guter Kompromiss.

TooManyParameter Metric

Je mehr Parameter eine Methode hat, desto schlechter ist diese nach CleanCode. Wie wäre es wenn diese gesondert markiert würden? Dabei sollte sowohl die Signatur markiert werden, als auch die Stellen an denen dieser Code verwendet würde.

Als Einstellmöglichkeiten könnte ich mir folgendes Vorstellen:

• Bei wie vielen Parametern soll Markierung beginnen? default 2
• Soll Definition markiert werden? default true
• Soll Verwendung markiert werden? default true
• Sollen Konstruktoren analysiert werden? default false

Die Konstruktoren würde ich außen vor lassen, da diese dank Dependency Injection sehr ausarten können. Vielleicht bedarf es hier aber auch nur etwas lockerer Definitionen, denn 10 Parameter im Konstruktor sind vermutlich ein Hinweis darauf, dass die Klasse zu viel zu tun hat.

Create config if absent

If no config file is found (in solution folder) then create a config file from defaults.

Frame height varies depending on visible part of method

When only a single line is visible, the frame just covers it:

As soon as more lines become visible by horizontal scrolling the frame increases in size and covers them all:

Frame disappears, if only method body is within scope

During using the plug I explored a property that yields lots of TestCaseData and therefore was pretty long. If method gets in scope, the red frame is drawn. But when only the methods body is within viewport, the red frame disappears. This can easily be testet be writing a long method that span over one screen high, or by making the viewport smaller. Here an example:

Complete method:

Method with signature and a part of the body in a small viewport:

Part of the methods body within a small viewport without frame:

Method with its closing brace within a small viewport:

Exclude functions from feedback

Exclude single methods from feedback eg. by adding an attribute on top of them:

[ForceFeedbackProgramming(Check=false)]
public void Do_sth(...) {
  //...
}

Such exclusions could be useful during a refactoring, to work without being hampered. Or really dirty methods could be excluded.

Ersten Eintrag in config streichen

In der config steht als erster Eintrag eine lines-Angabe ohne Farbe. Das ist unnötig und verwirrend.

Jeder Eintrag in der config soll angeben, ab welcher Zeilenzahl welche Farbe und welche Eingabeveränderung stattfinden soll. Unterhalb der Zeilenzahl des Eintrags mit der kleinsten Zeilenzahl passiert nichts.

Config editor

Add a "page" to the usual VS config editors. FFP configuration values then can be edited easily from within VS instead of fiddling with a JSON file.

That way it would be easy to differentiate between project, solution, and global config values.

AppVeyor CI aufsetzen

Die Extension autom. durch AppVeyor bauen lassen nach jedem Push zu Master.

Das resultierende Binary sollte anschließend auch autom. deployt werden, z.B. zurück ins Repo. Das kann mit Github-Releases gehen, wenn ich nicht irre. (Wenn VS Extensions auch über NuGet geladen werden können, dann am besten auch nach NuGet deployen.)

Über den aktuellen Build-Status sollte ein Badge auf der Home README-Seite informieren. Das bietet AppVeyor ja an.

Tastatureingabe stören

Die Eingabe von a-z/A-Z/0-9 soll in Abhängigkeit der Zeilenzahl gestört werden durch Einfügen dieses Zeichens: ⌫

Die Intensität der Störung wird in der config festgelegt:

    {
      "lines": 5,
      "color": "#888888",
      "transparency": 0.25,
      "noiseDistance": 3
    },

noiseDistance gibt an, alle wieviele Zeichen eine Störung eingestreut werden soll. Beim Wert 3 würde aus der Eingabe abcdefghi die Zeichenfolge abc⌫def⌫ghi⌫. Je geringer der Wert, desto geringer der Abstand zwischen den Störungen, desto höher das Rauschen.

Der kleinste Wert für noiseDistance ist 1: dann wird nach jedem Zeichen eine Störung eingestreut. Ein Wert <=0 oder ein fehlender Eintrag schalten die Störung aus.

Property get/set werden nicht eingefärbt

Trotz gewünschter Einfärbung ab 5 Zeilen ist hier keine Hintergrundfarbe zu sehen:

get/set Code wird wohl wie ctor Code gesondert im AST ausgewiesen.

Einfärbung setzt aus mit C# 6.0 Funktionsabkürzungen

Wenn die Funktion in der Mitte eingefärbt sein soll, müssen die beiden "Funktionsabkürzungen" nach C# 6.0 Syntax davor und danach auskommentiert sein:

Hier fehlen die Kommentare und die Einfärbung findet nicht statt:

Rough logging of core failures

When an exception occurs in the core then a log entry is created in .forcefeedbackprogramming.log in the sln folder.

For now the color red is returned as visual feedback only in that case.

Reintroduce config files to core

After the clean-up there are no config files anymore. They need to be put back in in general. At first this requires the core to be put under unit test and get config handling injected.

Selective feedback

Do not apply coloring and hampering equally to all functions. Exclude (or include) functions explicitly by through regular expressions.

A reg ex can be applied to the fully qualified name of a function (ie. including namespaces):

{ namespace { "." namespace } "." } classname "." functionname, e.g. myapp.mymodule.myclass.myfunction

Or the reg ex can be applied to the file path of the source code file:

"/" { foldername { "/" foldername } "/" } filename, e.g. /mysln/myproj/myfolder/myfile.cs

Using such patterns e.g. test code can be excluded from the feedback. Or code in legacy modules can be excluded.

Inclusin/exclusion patterns can be registered in the config file, e.g.

{
  "groups": [
    {
      "excludeModules": "test_[[:alnum:]]*\.[[:alnum:]]*$", // alle Funktionen in Klassen, die mit "test_" beginnen
      "excludeFiles": "Tests\.cs", // alle Funktionen in Dateien, die auf "Tests.cs" enden

      "methodTooLongLimits": [
         {
            "lines": 5,
            ...
         },
         ...
      ]
    },
    ...
  ]
}

groups define functions to apply the same metrics to for feedback. There can be several groups in each config.

Verschachtelungstiefe hervorheben

Ich fänd es super, wenn zusätzlich zur Zeilenanzahl auch die Tiefe der Verschachtelung (beispielsweise über die Anzahl der geschweiften Klammer) berücksichtigt würde. Die Blöcke innerhalb einer Methode könnten mit einer anderen Hintergrundfarbe markiert werden.

Config automatisch nachladen

Solange die Konfiguration noch per config.json stattfindet, sollte die Extension diese Datei beobachten und bei Veränderungen automatisch nachladen.

Tritt beim (Nach)Laden ein Fehler auf, kann die Extension den stillschweigend ignorieren und es nach einer nächsten Veränderung an der Datei erneut probieren.

Frame not properly positioned, if zoom is less or greater than 100%

Merge Issue18 into develop and close Issue18

Further development will then branch from develop.

Read config from resource

A default config is provided as a resource string. It is read by the config provider upon Compile().

This is a temp. solution until config files are searched and read.

Standard config.json

Wenn eine config.json fehlt, legt die Extension sie automatisch mit Standardeinstellungen an.

config.json aus der Root des Repo nehmen.

Konstruktor scheint ignoriert zu werden

Mir ist aufgefallen das der Konstruktur bei der Längenprüfung anscheinend ignoriert wird.

Versionsnummer fehlt

Neue Releases der Extension sollten eine wachsende Versionsnummer bekommen, damit sie leichter installiert werden können.

Bisher war die Versionsnr konstant. Daher musste eine alte Version erst deinstalliert werden, bevor die neue installiert werden konnte.

Rahmen verschiebt sich nach Zoom

Wenn man den Code mit Mausrad oder per Menü zoomt, verschiebt sich der Rahmen. Wenn man auf >100% stellt, wandert der Rahmen nach rechts in den Code, bei <100% wandert er nach links vor den Code.

Die Größe des Rahmens scheint passend und relativ zur Zeilenbreite. Er ist nur eben nicht korrekt links positioniert.

Logging errors

Errors (exceptions) which happen during execution of the extension should be logged somewhere. Maybe in a VS window (eg error log). Or at least in a textual log file in the folder of the current project (eg ffp.log). This log file could be reset with every VS start.

Leerzeilen und Kommentare optional ausschließen.

Man sollte Leerzeilen und Kommentarzeilen jeweils optional über die Konfigurationsdatei aus der Funktionslängenberechnung ausschließen können.

Inkrement #1: Binär einfärben

Der Hintergrund jeder Methode wird je nach Anzahl der Zeilen eingefärbt:

• 0..10 Zeilen: keine Farbe

• 10 Zeilen: hellgrau

Die Einfärbung tritt sofort ein, wenn die Zeilenzahl die Grenze über/unterschreitet.

Farbe und Grenze sind im Code hart verdrahtet.

Lieferdatum: 13.5.2015

Retarding key presses

Keys pressed (a-zA-Z0-9) will not be changed, but retarded. They don't appear immediately but only after a (short) while:

    {
      "lines": 5,
      ...
      "keystrokeDelayms": 100
    },

With the entry every relevant key pressed would be delayed by 100ms. Adding code would slow down quite a bit.

A missing value or 0 would switch off retardation. Values from 1 to 1000 are valid. (Delays of more than 1000ms seem impractical.)

Such delays are independent from inserting disturbances. It seems best to first delay and then insert additional characters.

Auf Tastatureingabe reagieren

Bei jedem Buchstaben (a-z, A-Z) und jeder Ziffer (0-9) eingegeben in einer Methode, die schon eingefärbt ist, den Rahmen "flackern lassen". Die Farbe des Rahmens könnte zwischen Schwarz und der eigentlichen Rahmenfarbe wechseln.

Die Tastatureingabeerkennung greift hier auf dieselben config-Einträge zurück wie das Einfärben. Das kann wahrscheinlich auch so bleiben. Später werden die config-Einträge dann einfach um eine Angabe erweitert, was ab bestimmter Zeilenzahl mit Eingabe passieren soll.

Transparenz wird falsch interpretiert

Ein kleiner config-Wert transparency wird als große Transparenz interpretiert, z.B. führt der Wert 0.25 durch schwacher Deckkraft (aufgrund hoher Transparenz) und der Wert 0.75 führt zu hoher Deckkraft (aufgrund geringer Transparenz).

Entweder also korrekt interpretieren (kleiner Wert bedeutet kleine Transparenz, also hohe Deckkraft). Oder Interpretation unverändert lassen und den config-Wert in opacity umbenennen.

Implement tactile noise feedback

Noise needs to take into account how many consecutive (!) changes have been made to a method! Some state needs to be kept for that, probably.

Also: The noise string should be generated randomly.

Konfigurieren des binären Einfärbens

Zeilenzahl und Farbe fürs Einfärben sollen aus einer Json-Config-Datei gelesen werden, z.B.

{
  colorings: [
    { lines: 10, color="#D3D3D3", transparency=0.25 }   
  ]
}

• lines: Zeilenzahl ab der die Farbe zum Einsatz kommen soll.
• color: RGB-Farbe codiert wie hier beschrieben: http://www.rapidtables.com/web/color/RGB_Color.htm. Farbwert im Beispiel für lightgray hier entnommen: http://www.rapidtables.com/web/color/gray-color.htm
• transparency: Angabe im Bereich 0..1 für 0% bis 100%, 0%=deckend/intransparent, 100%=volltransparent

colorings ist schon als Liste ausgelegt, weil zukünftig ja viele Einfärbungen definiert werden können. Im Moment jedoch hat die Liste nur 1 Eintrag. Im Code geht es nur um die Veränderung der Quelle für die Einfärbungsdaten!

Implement tactile delay feedback

Rename config file

The config file should be renamed to .forcefeedbackprogramming.

This would follow the convention for config files in some other tools.

A file with this name can exist on all levels: project, sln, and global.

Existing config files should be renamed automatically.

Documentation missing

It is not clear what the certain parts of the source code mean.

• What's the purpose of the ForceFeedback.Setup project?
• What are the entry points (controllers) into the extension? What are the API classes/methods?
• Where does the CI, how does it work?

This all might seem obvious to the author of the code/infrastructure - but it's not for someone who is new to the repo. Getting up to speed quickly and easily however seems crucial if help is to be attracted.

Search for config

Search for config in folders passed to config provider in this order: file folder, prj folder, sln folder.

Pick first config found. If none found, create a default config in sln folder.

Implement visual feedback

Visual feedback is given during redraw and after changes were applied.

Solution/project specific config

To make the feedback specific to a code base the config file should be local e.g. ffp.config.json in the folder of the solution.

The extension for sure can find out which solution is open at the moment and check in its folder for a specific config before grabbing the global one.

Even project specific config could be possible.

Support for Visual Basic projects

Does not work for Visual Basic projects, does it?

Update config documentation

Update documentation according to how config files now look and are handled.

Portal und Domäne trennen

Derzeit vermischt die Assembly ForceFeedback.Rules.dll zwei Verantwortlichkeiten:

• Zum einen ist sie Schnittstelle zur Umwelt; sie kapselt den VS Extension API. MethodTooLongTextAdornment{} ist der Handler für Ereignisse, die in VS ausgelöst und wo Veränderungen am DOM vorgenommen werden.
• Gleichzeitig wird im Handler aber auch entschieden und getan, was der Domäne entspricht.

Beide Verantwortlichkeiten sollten auf unterschiedliche Klassen oder noch besser Assemblies verteilt werden. Gerade wenn die Domäne in einer eigenen Assembly gekapselt ist, sind Veränderungen daran möglich, ohne Kenntnisse des VS Extension APIs zu haben.

Für eine solche Trennung ist natürlich eine geeignete Schnittstelle zu finden. Beispiel:

interface IForceFeedback {
  void Configure(Configuration config);

  Coloring Determine_method_coloring(string methodname, int numberOfLinesOfCode);
  Noise Determine_typing_noise(string input, string methodname, int numberOfLinesOfCode);
}

struct Coloring {
  public RGB BackgroundColor;
  public int Transparency; // 0..100
}

struct Noise {
  public string Input;
  public int Delayms; // 0..1000
}

Zweierlei würde in dieser Schnittstelle fixiert: dass es um Colorierung und Eingabestörung geht sowie dass die Metrik LOC ist.

Ersteres lässt sich kaum vermeiden. Finde ich aber auch nicht schlimm.

Letzteres ließe sich vermeiden, wenn in die Domänenmethoden der Quelltext hineingereicht würde. Dann könnte die Domäne eine Analyse nach Belieben darauf anwenden.

Aber ich denke, im Moment können wir mit der Vorgabe LOC leben.

Selektionen nicht immer sichtbar

Hier ist eine Selektion vollständig sichtbar:

Aber hier ist sie kaum noch sichtbar:

Die Ursache scheint in der Transparenz der Einfärbung zu liegen. Ist die hoch, dann sieht man die Selektion. Je weniger transparent die Einfärbung jedoch, desto weniger sieht man die Selektion. Anscheinend liegt die Selektion in einer Ebene unterhalb von Text und Einfärbung.

Solange das so ist, kann die Transparenz kaum genutzt werden, um Farbschattierungen zu erzeugen.

Read config from file

The configuration is read from a file present in the solution folder passed to the configuration provider.

Funktionsrumpf nicht einberechnen.

Bei der Ermittlung der Funktionslänge sollte der Funktionsrumpf nicht mit einberechnet werden.
Natürlich könnte man auch in der Konfiguration einfach 3 Zeilen dazu rechnen. Aber automatisch wäre es schöner.

Visual Studio 2017 Support

Hey Robin,

Just wanted to say love the plug-in was wondering if you are going to support VS 2017.

Thanks,
Eric

Fixed in-mem default config

Let machine base its work on a default in-mem configuration.

Make hampering more intense

So far developers are hampered while entering source code by inserting singe characters. To irritate them even more such disturbances could consist of several characters:

    {
      "lines": 5,
      ...
      "noiseDistance": 3,
      "noiseIntensity": 2
    },

The value noiseIntensity defines how many characters should be entered per disturbance. The value 2 would lead change the input "abcdefgh" to "abcXXdefXXgh".