Mirror of forum.nim-lang.org

13730 :: Best Practices and Style Guidelines for Nim

• planetis (orginal) [2026-02-17T11:21:14+01:00] view original

  Has anyone tried to create a SKLIL.md for writing high-quality Nim code? I’m using Codex to write code, and I’m shocked by how many shortcuts it takes that avoid good coding practices for example, using early returns everywhere. I don’t want to use structured programming exclusively, but rather a balanced approach, using a result variable where it makes sense, and return where it doesn’t. I’m looking for some relaxed rules and guidelines on what good Nim code should look like. Has anyone tried something like this?

---

• planetis (orginal) [2026-02-17T11:21:30+01:00] view original

  And if not what would you include?

---

• Araq (orginal) [2026-02-17T11:46:19+01:00] view original

  The AIs tend to feel my presence and obey the existing code structure. Would probably be different for me if I had projects created from scratch.

  So in other words, "follow the style of project XY" (that is part of your workspace) as an instruction might get you somewhere.

---

• 3-2-1 (orginal) [2026-02-17T15:54:51+01:00] view original

  I'm curious, outside of using Cursor, what is your workflow these days, Araq?

---

• Araq (orginal) [2026-02-17T17:47:33+01:00] view original

  1. Keep the context to a minimum, start a new session after 2-5 queries. IME Claude Opus 4.6 can get "tired" like all the other models, maybe even moreso.
  2. AI excels at translation tasks, "translate this code to TLA+", "write test cases for X".
  3. AI also excels at writing small programs, great for performance optimization, have it try out 3 competing algorithms and benchmark it.
  4. AI is also great for "fuzzy queries" like "find me the one interesting code section in async is that sets x to nil in order to breakup cycles".

  Review the diffs as carefully as if a new coworker had written the code.

---

• ITwrx (orginal) [2026-02-17T18:08:55+01:00] view original

  I agree with @araq, they do everything better once there is sufficient codebase/project structure for it to analyze. Starting from scratch, it makes lots of bad decisions. If starting from scratch, you can tell it to use the same coding style or organization as a FOSS repo or local code you have. I did that, and it worked much better than watching it make bad decisions and then griping at it. like this: https://www.youtube.com/watch?v=_2C2CNmK7dQ or maybe this? https://www.youtube.com/watch?v=JeNS1ZNHQs8

---

• planetis (orginal) [2026-02-17T20:21:11+01:00] view original

  This is great advice. All that’s needed is a minimal sample of “good” style, according to your taste something that doesn’t fill up the context, is easy to customize, and contains enough options to be considered complete. I think I’ll start with that idea, because trying to express what I want in words is tiresome, and it’s hard to communicate with dumb AI, while chatbots are very good at imitating style. Thank you both for the suggestions!

---

• mig (orginal) [2026-02-17T20:40:00+01:00] view original

  Why are you putting code style in SKILL.md? Put it in AGENTS.md and to have it in the context all the time IMO.

  For Nim code, I think these are necessary at the minimum:

  1. Combine let/var/type sections into one section (with an example of what to do vs. what not to do)
  2. Avoid early returns and use result variable when necessary
  3. Prefer named tuples, e.g. tuple[a: string, b: int] over (string, int)
  4. Do NOT add redundant comments (this is a problem with opus in general)

---

• Araq (orginal) [2026-02-17T20:56:30+01:00] view original

  1.) No, the opposite, except for type. Reason: I don't know, I just prefer it this way. 2.) Yes. 3.) No, instead use a real object type, tuples are overused, leads to tuple unpacking, leads to inconsistent names and possible ordering bugs. 4.) Yes, but also: Document the why, not the how. Lawrence Krauss doesn't believe in "why", that's ok, he won't read the code.

---

• lou15b (orginal) [2026-02-18T15:55:20+01:00] view original

  Document the why, not the how.

  I suggest a refinement: for any relatively complex chunk of code (block, proc, but especially macro), document the intent. In other words, what is that code intended to accomplish. Vital to anyone trying to understand it - including oneself some weeks/months/years after writing it.

---