Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add numbers to all Errorfs #560

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

Reasonable-Solutions
Copy link
Contributor

I did it over all fmt.Errorfs instead of finding the useful ones 🙃

@Reasonable-Solutions Reasonable-Solutions requested a review from a team as a code owner September 2, 2024 10:04
@mortenlj
Copy link
Contributor

mortenlj commented Sep 2, 2024

Hva er mekanismen for å velge en feilkode? Regner med at det ikke er 9776 forskjellige feil i naiserator, så da er det ikke en ren teller ...

Kanskje dokumentere hvordan man velger seg en ny feilkode i README?

@jhrv
Copy link
Contributor

jhrv commented Sep 2, 2024

Og kanskje også bli enige om hvordan en sånn her feilkode-mekanisme skal virke, og om man skal ha det

@Reasonable-Solutions
Copy link
Contributor Author

Reasonable-Solutions commented Sep 2, 2024

Hva er mekanismen for å velge en feilkode?

Random uniform sampling on the intervall 0-9999.
I did something like this:

find . -type f -name "*.go" | while IFS= read -r file; do
  awk '{gsub(/fmt\.Errorf\("/, sprintf("fmt.Errorf(\"NAISERATOR-%04d: ", int(rand()*10000)))}1' "$file" > temp && mv temp "$file"
done

Paraphrasing from another project where we did this:

"
Codes should not be organised based on the type of error (like using one set of numbers for type errors, another for parser errors, etc.). This is for several reasons: codes might be used in different parts of the tool over time, but their meaning stays the same (so the internal workings of the tool shouldn’t determine the codes). Also, one group might run out of codes, and grouping similar messages by code might make it harder to choose the right one from a list.

Codes also shouldn’t be assigned in order based on the tool’s source code, because this could suggest a misleading pattern, and sequential numbers aren’t visually distinct enough.

For tools that have development branches that last a long time, there should be a way to prevent code conflicts between branches. This helps avoid accidentally using the same code twice and reduces the chance of merge conflicts when combining code from different branches.
"

If you're feeling fancy, I use the following for outputting new NNNN numbers as I code:

  (defun carl-insert-error-number (&optional reroll)
  "Generate a random number in the format NNNN with zero padding.
Insert the number at the current cursor position.
If called with a prefix argument (C-u), it will search the project
for the generated number and reroll if the number is found."
  (interactive "P")
  (let (random-number)
    (catch 'reroll
      (while t
        (setq random-number (format "%04d" (random 10000)))
        (if (and reroll
                 (let ((default-directory (project-root (project-current t))))
                   (not (string-empty-p (shell-command-to-string
                                         (format "git grep -n %s" random-number))))))
          (throw 'reroll random-number))))
    (insert random-number)

@Reasonable-Solutions
Copy link
Contributor Author

Kanskje dokumentere hvordan man velger seg en ny feilkode i README?

Definitively.

I blanket-awked this instead of finding the useful ones.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants