{"id":23515072,"url":"https://github.com/rcedgar/re_coding_style","last_synced_at":"2026-02-01T15:34:54.467Z","repository":{"id":244871428,"uuid":"815979084","full_name":"rcedgar/re_coding_style","owner":"rcedgar","description":"Robert C. Edgar's C++ coding style","archived":false,"fork":false,"pushed_at":"2024-06-17T23:59:40.000Z","size":4,"stargazers_count":5,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-06-09T13:52:13.591Z","etag":null,"topics":["computer-science-algorithms","programming","programming-style"],"latest_commit_sha":null,"homepage":"https://drive5.com/","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/rcedgar.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-06-16T17:59:11.000Z","updated_at":"2024-09-11T14:31:00.000Z","dependencies_parsed_at":"2024-06-18T01:04:33.751Z","dependency_job_id":null,"html_url":"https://github.com/rcedgar/re_coding_style","commit_stats":null,"previous_names":["rcedgar/re_coding_style"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/rcedgar/re_coding_style","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rcedgar%2Fre_coding_style","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rcedgar%2Fre_coding_style/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rcedgar%2Fre_coding_style/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rcedgar%2Fre_coding_style/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/rcedgar","download_url":"https://codeload.github.com/rcedgar/re_coding_style/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rcedgar%2Fre_coding_style/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28981154,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-01T13:38:33.235Z","status":"ssl_error","status_checked_at":"2026-02-01T13:38:32.912Z","response_time":56,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["computer-science-algorithms","programming","programming-style"],"created_at":"2024-12-25T14:12:51.104Z","updated_at":"2026-02-01T15:34:54.453Z","avatar_url":"https://github.com/rcedgar.png","language":null,"readme":"# re_coding_style\n\n# Robert C. Edgar's C++ coding style\n\n### Local, member and global variable names\n\nMember variables have the `m_` prefix, globals are named `g_`, local variables have no special prefix.\nStatic global variables are not distinguished from exported variables (probably better would be to\nuse `s_` for static global). Command-line options are `opt_name` or `opt(name)`.\n\n### Error handling\n\nExceptions must not be used (see below). Flow-of-control statements for handling errors must be minimized; a given\nfunction should have have either (a) error control flow or (b) algorithm flow, but not both. This is typically\nimplemented by having small functions which quit with a fatal error if an operation fails, for example\n`OpenStdioFile()` will call `Die()` if it fails so that the calling code does not have to check for a zero return\ncode, it can continue assuming the file was opened successfully.\n\n### Exceptions never used\n\nReading Scott Meyers' Effective C++ books convinced me that writing robust, multi-threaded C++ code with exception handling\nwas close to impossible. Certainly impractical for me; way beyond the amount of effort I was willing to invest in\nfiguring out reliable design patterns and coding habits.\n\n### Hard-coded lists should behave like data not code\n\nLists of things crop up often in my kind of C++ code. A good example is command-line options (see below). If you can write\nan enum with the list once, and this covers all the use-cases, fine. But often it doesn't, with the result that coding\neffectively all its members crop up repeatedly, e.g. switch statements with one case per member having a\ncookie-cutter statement. Maintaining scattered uses of essentially the same list is tedious and error prone. \nTherefore, I often use an #include hack so that the list is maintained only one place. Maybe modern C++ has\nbetter solutions; please let me know if you have a suggestion (open an issue in this repo).\n\n### Command-line options\n\nI strongly dislike the typical command-line parsing in most C and C++ programs I see in bioinformatics. They are hard-to-read\nand hard-to-maintain spaghetti. I prefer *al dente*. I want the command-line parsing as such to be written once and forgotten,\ncleanly separated from the list of options. Using an option should have minimal run-time overhead such that they can be accessed\nanywhere except perhaps innermost loops. Warnings should be issued for unused options to mitigate the difficulty in\ndocumenting which options apply to which commands. The set of options is a list requiring #include hacks (see above).\nA variable which is an option should be evident in the code; this is achieved by calling a global variable `opt_name` or\nby using macro `opt()` (only one of these styles applies, depending on which version of `myutils` is included).\nA global boolean `optset_name` is used to check if the option was set on the command line.\n\n### Commands\n\nA command is a special case of a command-line option. It always takes a string value. The list \nof commands is in `cmd.h`.\nThe main program will call a function named `cmd_name()` for command `name`, e.g. if the command line\nstarts with `-usearch_global` then `main()` will call `cmd_usearch_global()` with no arguments. To access\nthe value, use `opt(usearch_global)` or `opt_usearch_global` depending on the version of `myutils`.\nIn more recent code, the global variable `g_Arg1` has the string value of the command option.\n\n### Memory allocation\n\nI use `myalloc` and `myfree` to wrap `malloc` and `free` so that fatal errors can be issued; calling code can\nassume that the functions succeeded. `myalloc` is a macro, usage is `myalloc(typename, n)` to allocate\na bufferfor a vector of length `n`, e.g. `myalloc(int, 10)`.\n\n### Assertions\n\nI assert everything I can think of, usually with `asserta` (\"assert always\", i.e. even in a Release build)\nunless there is likely to be a meaningful execution penalty, i.e. the assertion is in a\ncritical inner loop.\n\n### Separating interface from implementation\n\nI prefer to separate interface from implementation. For example, template classes are very powerful, but\nI try to avoid them because the interface is hard to see and the implementation must be written as a \nlong header file which I find difficult to navigate and to think about when I'm looking at it.\nI do use them in a few cases, e.g. `Mx\u003c\u003e` in `mx.h`. For non-trivial code,\nI prefer short functions in short source files; then the code I'm looking at does one well-defined\njob without being surrounded by distracting noise. Sometimes my `.cpp` files do get quite long, \nin a weak violation of this guideline, but in these cases I usually have a shortish `.h` file defining\na class interface, and Visual Studio allows me to jump straight to the member function by pressing `[F12]`\nso I don't have to scroll around to find it.\n\n### Modern C++\n\nMy C++ syntax mostly fossilized in the early 2000's. This is partly laziness (I haven't bothered\nto learn the new stuff) and partly for practical reasons: using a conservative subset of C++\nimproves portability and helps make it accessible for collaborators having varying expertise.\n\n### Integers are usually `uint`\n\nblah\n\n### The `SIZE()` macro\n\n### Looping over containers\n\n### Portability to Linux, Windows and OSX\n\n### `myutils.cpp` and `myutils.h`\n\n### CamelCase identifiers\n\nI generally use CamelCase. Recently I've found that I prefer typical python \nstyle (see e.g. [https://google.github.io/styleguide/pyguide.html](https://google.github.io/styleguide/pyguide.html)\nbecause CamelCase requires way too many Shift-key presses making it harder to type.\n\n### Dependencies\n\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frcedgar%2Fre_coding_style","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frcedgar%2Fre_coding_style","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frcedgar%2Fre_coding_style/lists"}