How would you structure programming notes?

Questions & Help
1

What is the best approach to structure technical notes for programming? These subjects have a clear structure. So it’s easy to create a hierarchy and figure out where everything goes.
There was a graph shared by Ramses Oudt in one of the query challenges where he uses namespaces to structure CSS notes. I have attached a screenshot bellow. Is this the recommended way?

Screenshot from 2024-04-21 17-25-25
Screenshot from 2024-04-21 17-25-25592×700 53.8 KB

2
  • Namespaces
    • are not meant for hierarchies
      • When used this way, they cause more pain than benefit.
        • Therefore, I don’t recommend this way.
    • are useful for disambiguation
      • i.e. if two concepts in the same graph happen to have identical names
        • Otherwise, each concept has a name and it should become a page of that name.
          • No special parent is needed.
            • They already have the graph as their parent.
  • Let’s take the last line of your screenshot.
    • CSS should probably be the name of the graph
      • If that’s not the case, please get more specific on what you want to put in your graph.
    • position should be the name of a page
      • This is a first-level concept that deserves its own page.
    • property should be the value of page-property type:: of page position
      • This is a higher-level concept, used in the meta-data of first-level concepts.
    • sticky should be an individual note-block within page position
      • This is not a concept, therefore not deserving a page.
        • Generally indicated by not being a noun.
1 Like
3

I want to put all web development and some CS notes in a single graph.

If CSS is not the name of the graph, but is one of the main topics, how would you change this structure?

4
  • Sounds like your graph should be named web development
  • In the earlier example:
    • the page position should become either:
      • CSS/position
      • simply css position
    • the value of the property type:: should become either:
      • CSS/property
      • simply css property
    • the rest remain the same
5

Why use type instead of tags?
My current approach is to only use tags. That way if I open a page, let’s say a called Cascade, I get the pages tagged with section. If I use other properties that information is not available.

6
  • More specific properties (here type) enable more specific filtering.
    • The bigger a graph gets, the bigger the need for specific filtering.
  • tags is a built-in property that comes with predefined behavior.
    • There are ways to make any property behave (almost) like tags .
7

Ok, thank you very much.