C#: Not-nullable reference types

As it turns out, C# has support for non-nullable reference types, that is, variables with reference types (typically object types) that may not be assigned null. The following thus is illegal:

object foo = null;

This requires a compiler switch to be set at the project level, to enable a so-called “nullable annotation context”. This tells the compiler to infer nullable state for all variables, and warn in any situations where a regular reference variable may turn null. A typical example might be a declaration without assignment, which would get null default-assigned. Of course, you can declare a variable to possibly be null just like for value types by appending ?.

It’s a pitty this is turned into a compiler flag: Now, when reading C# code, you can not really be sure if it was written with a certain nullability checking in mind. While I see the useful reason of backwards compatibility, having this enforced for everyone everywhere would clear up this possible missunderstanding. In fact, as the checks only yield warnings, not errors, this would not even be a blocker. Of course, you can convert these warnings to errors, if you are so inclined.

You can enable the setting by adding the Nullable setting to all .csproj files:


Apparently, they don’t mix well with structs and arrays; I’d recommend to stick to references and lists.

Also, parameters can receive a rather detailed set of attributes to denote behaviour wrt. nullability. For example, a method can declare that it will not return null when a specific parameter is not null as well.

Ten Usability Heuristics

Jakob Nielsen writes about the 10 Usability Heuristics for UI Design. These are rules of thumb, which most often (but not always) hold true:

  1. System status should always be visible.
  2. The system should use the same words as the users.
  3. All actions should have easy “I did not want to do that” functions like undo.
  4. The system should adhere to standards and be consistent in its presentation.
  5. The system should avoid erroneous states with constraints and useful defaults.
  6. Make actions, elements and options visible to replace recall with recognition.
  7. Frequent actions should be personalisable.
  8. Reduce the interface to required information; form follows function.
  9. Support users in detecting, diagnosing and recovering from errors.
  10. Provide useful, searchable help.

The heuristics have persisted since 1996, that is, the time back when interface design was mostly clunky and grey; even several revisions have kept them mostly intact. I guess there seems to be something to them if they survive that long.

Patterns 42, from Arc42

The team of Arc 42 (the architecture documentation template) collects a set of patterns on a seperate subsite: https://patterns.arc42.org/home/

The site seems to be somewhat current, with most content on the corrensponding GitHub repository from about 2018.

The Pattern cover mostly large scale system patterns, but include some of the better known GoF patterns as well. Patterns include:

  • Hexagonal Architecture
  • MicroServices
  • Anti-Corruption-Layers
  • Design Patterns from GoF

Remote Working Guide at GitLab

The folks at GitLab have been working in a full-remote scenario not only since the current epidemic, but ever since they started. They gathered a lot of experience in remote working, and have created a quite voluminous Remote Playbook (which you can download there) as well as equally detailed guide to working all-remote.

They abstract their philosophy with a Remote Manifesto similar to the agile one:

  1. Hire people from everywhere
  2. Enable flexible working hours
  3. Prefer written documentation to oral
    • This is a little surprising to me. While I do know that documentation is important, obviously, I currently feel that verbal communication seems the more natural, and thus the easier way.
  4. Prefer written processes to guided training
    • Similar to above.
  5. Public sharing of information
  6. Let anyone edit any document
  7. Communicate async over synchronous channels
  8. Results over work time
  9. Prefer formal communication channels
    • Curious about this as well, especially how they define the difference between formal and informal channels. Does it suffice to have a company slack server?

Guide Lines für Code Reviews von Gitlab

Der Gitlab-Blog schreibt zum Thema Code Reviews:


Wichtige Tools eines Code Reviews:

  • Self Reviews: Vor dem Zuweisen eines PRs selbst in eine Reviewer-Rolle schlüpfen.
  • Checkliste: für den Author:
    • Jede Code-Zeile nochmal lesen
    • Code lokal testen
    • Für jede Änderung einen Test schreiben
    • Klare Beschreibung schreiben und nach jedem Feedback aktualisieren
    • Mindestens einen Screenshot pro PR
    • Vorgreifend potentielle Fragen beantworten
  • Conventionale Kommentare: Emotion/Intention in Kommentaren ausdrücken. Siehe https://conventionalcomments.org/
  • Patch Files: Kommentare mit Patches versehen, um Vorschläge zu vereinfachen
  • Fairness: Sowohl als Author als auch als Reviewer:
    • Sei belastbar, zuverlässig, fair und respektvoll.
    • Suche stets Wege, um zu jedem fair zu sein.
    • Als Author: (unter anderem) Versuche Fragen in dem PR zuvorzukommen, und seltsame Teile vorgreifend zu erläutern
    • Als Reviewer: Berücksichtige “unbewusste Voreingenommenheit“: Jedes “sollte” oder “muss”/”müsste” muss eine Begründung (Link zu Dokumentation/Konvention) haben, ansonsten ist es nur eine persönliche Präferenz!
    • Wenn du anderer Meinung bist: Frage warum, anstatt eine andere Lösung zu verlangen.
  • Follow Up: Verschiebe größere Anmerkungen/Diskussionen in andere PRs oder Besprechungen.
    • Stelle sicher, das diese auch stattfinden!
  • Die Kunst des GIFs: Nutze GIFs, um PRs emotionaler und menschlicher zu gestalten.
  • Kleine Iterationen: Breche PRs in kleinere Teile auf. Je kleiner, desto besser zu reviewen!