{"id":16882871,"url":"https://github.com/alhadis/coding-style","last_synced_at":"2026-01-04T00:42:23.824Z","repository":{"id":78377324,"uuid":"54219184","full_name":"Alhadis/Coding-Style","owner":"Alhadis","description":"Personal coding preferences I hope everybody reads.","archived":false,"fork":false,"pushed_at":"2021-10-01T14:27:03.000Z","size":509,"stargazers_count":13,"open_issues_count":0,"forks_count":0,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-01-25T06:41:54.444Z","etag":null,"topics":["indentation","semantic-formatting","styleguide","styleguide-javascript","tabs"],"latest_commit_sha":null,"homepage":"","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/Alhadis.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":"2016-03-18T17:22:04.000Z","updated_at":"2021-10-01T14:27:06.000Z","dependencies_parsed_at":"2023-05-21T13:00:43.376Z","dependency_job_id":null,"html_url":"https://github.com/Alhadis/Coding-Style","commit_stats":null,"previous_names":[],"tags_count":3,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Alhadis%2FCoding-Style","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Alhadis%2FCoding-Style/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Alhadis%2FCoding-Style/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Alhadis%2FCoding-Style/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Alhadis","download_url":"https://codeload.github.com/Alhadis/Coding-Style/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":244554126,"owners_count":20471173,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","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":["indentation","semantic-formatting","styleguide","styleguide-javascript","tabs"],"created_at":"2024-10-13T16:08:58.372Z","updated_at":"2026-01-04T00:42:23.794Z","avatar_url":"https://github.com/Alhadis.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"You have open before you an unavoidably arrogant avalanche of bikeshedding which\nserves as an explanation of my personal coding style. While I don't envision any\nof my projects ever becoming a conduit for collaboration (since I prefer working\nalone), I'll at least have something in black-and-white to direct anybody to who\nfeels compelled to send a PR on one of my projects.\n\n**~~Table~~**\n**TL;DR of contents:**\n\n1.  [Use tabs for indentation](#1-use-tabs-for-indentation)\n2.  [Don't use tabs for alignment](#2-dont-use-tabs-for-alignment)\n3.  [K\u0026R bracing style](#3-bracing-style)\n4.  [Casing style](#4-casing-style)\n5.  [Use semicolons](#5-semicolons)\n6.  [Double-quotes](#6-double-quotes)\n7.  [Comma-last](#7-comma-last)\n8.  [Writing commit messages](#8-writing-commit-messages)\n9.  [No emoji](#9-no-emoji)\n10. [No commit prefixes](#10-no-commit-prefixes)\n11. [Line length](#11-line-length)\n12. [Use standard English](#12-use-traditional-english-spelling-british-english)\n13. [Conclusion](#conclusion)\n\nLet's get this shed painted.\n\n\n1․ Use tabs for indentation\n--------------------------------------------------------------------------------\nUse hard tabs `(U+0009)` to indent.\n\nIf you prefer spaces for indentation, I'm automatically inclined to dislike you.\nReally, I'm not joking. I wish I were, as it'd imply I DON'T get eye strain when\nI try squinting through cramped columns of 2-space-indented JavaScript that kids\nthese days seem to think is trendy (and some adults for some reason).\n\n![Proud to detest the so-called JavaScript \"Standard\" Style](img/figure-1.png)\n\nEverybody has their own preference on what they're most comfortable reading. Let\nthem enjoy it, use tabs, and *use them responsibly*. Which brings me to point 2:\n\n\n2․ Don't use tabs for alignment\n--------------------------------------------------------------------------------\nNever assume a tab will be of any particular length, even if your project has an\n`.editorconfig` file. Imagine a tab is an invisible, elastic region of space the\ncoder can fluidly adjust to control their code's layout. Which it is.\n\nUse spaces for cosmetic alignment. Don't let them touch leading tabulation - tab\ncharacters should *never* come after a non-whitespace character (unless it's TSV\ndata, but obviously that's a given).\n\nAvoid situations where it's tempting to use tabs as an alignment device:\n\n    var a = \"This is\",\n        b = \"A common pattern\",\n        c = \"in JavaScript\";\n\nI find this to be more readable:\n\n    var a = \"This is\";\n    var b = \"Slightly less\";\n    var c = \"Common in JavaScript\";\n\nI'm okay with the first notation, as long as it's used like this:\n\n    var a = \"This is\",\n    b     = \"Weird\",\n    c     = \"Right?\";\n\nIf you're the comma-first sort of person (which I am *NOT*), you could do this:\n\n    var a = \"I hate\"\n    ,   b = \"This form\"\n    ,   c = \"Of notation.\"\n\nI think you get it.\n\n\n3․ Bracing style\n--------------------------------------------------------------------------------\nI prefer the K\u0026R style, with curly-brackets only appearing on their own lines if\nthe construct they're a part of can't be nested. For instance, in PHP, you can't\nhave one class inside another, so this is fine:\n\n    class Store\n    {\n        function query($args = array()){\n            \n        }\n    }\n\nSimilarly, if it's a C project, the same logic applies to functions (which can't\nbe nested):\n\n    int main(int argc)\n    {\n        while(true){\n            printf(\"Piss off world, I'm working.\\n\");\n            return 1;\n        }\n    }\n\nI generally prefer no spaces between the closing bracket and the opening bracket\n(e.g., `function name(){`), but I won't bite your head off for inserting a space\nfor readability. Unless of course, you're going around making wanton adjustments\nto existing code. If your PR's diffs crackle with noisy, irrelevant and cosmetic\nchanges, it's getting kicked.\n\n\n4․ Casing style\n--------------------------------------------------------------------------------\nDepends on language. Stick to the style used by a language's standard library:\n\n* camelCase:  JavaScript, Haskell\n* kebab-case: Anywhere where dashes are legal - HTML, CSS and filenames\n* snake_case: Anywhere where dashes *aren't* legal (PHP, Perl, most languages)\n\nCapitalisation follows the usual conventions of most programming languages:\n\n* Classes: PascalCase\n* Constants: SCREAMING_SNAKE_CASE\n* Anything else: lowerCase / lower-case / lower_case\n\nNOTE: My capitalisation of variable names is sometimes inconsistent when writing\nshell-scripts and Makefiles. Generally I'll start out writing them in UPPERCASE,\nthen switch to lowercase when there're too many variables making everything look\ntoo shouty.\n\n\n\n5․ Semicolons\n--------------------------------------------------------------------------------\nUse them. They make unfamiliar code easier to skim through by showing where each\nstatement terminates, distinguishing those split across multiple lines:\n\n    let list = items\n        .filter(a =\u003e a !== unwanted)\n        .sort(a =\u003e a \u003c b)\n        .join(\" \")\n        .replace(/[A-Z]zip/g, \"\")\n        .etc();\n\nThey're also not optional in every programming language. Trying to remember what\nlanguages have ASI and which don't is harder than simply hitting that damn extra\nkey. And if that's too much effort for you, well, I imagine your emails probably\nlook like this:\n\n\u003e hey sup. i pushed a few comits last nite.  \n\u003e did you remember the question mark  \n\u003e what's the url\n\n\n6․ Double-quotes\n--------------------------------------------------------------------------------\nUse double-quotes, unless it's a language sensitive to interpolation (like shell\nscripts, Perl, or PHP). An exception is a string containing double-quotes of its\nown: if using single-quotes helps eliminate escape characters, use them instead:\n\n    '\"Use This\"'\n    \"\\\"Not this\\\"\"\n\nBecause there's a difference between enforcing consistency and using your brain.\nIt looks like this:\n \n    \"- \\\"\" + name + \"\\\": \\\"\" + value + \"\\\"\"\n\nInstead of this:\n\n    '- \"' + name + '\": ' + value + '\"'\n\nThat being said, don't quote keys in object literals if they don't need it:\n\n    var obj = {\n        \"This needs it\": 1,\n        thisDoesNot:     1\n    };\n\n**Reason behind preference:**  \nDouble-quotes are easier to distinguish at a glance than apostrophes. Sure, they\ninvolve holding an extra key. Who cares? Get a better keyboard if pressing shift\nkeys is too cumbersome for you.\n\n\n7․ Comma-last\n--------------------------------------------------------------------------------\nNobody writes like this  \n, so neither should you  \n, unless you had one really  \n, really  \n, really  \n, really  \n, really weird education.\n\nBut hey  \n, less noise in your diffs  \n, right? RIGHT?\n\n\n\n8․ Writing commit messages\n--------------------------------------------------------------------------------\n[This entire damn article](http://chris.beams.io/posts/git-commit/). Every point\nis like holy Git law to me. BE FOREWARNED: Not adhering to these points WILL get\nyour PR rejected. The reason is simple: a commit message is permanent. Yes, it's\npossible to modify through rebasing, but that defeats the purpose of maintaining\nan honest and transparent modification history (and I'd rather not clobber a SHA\nhash just to amend the tone of a commit message).\n\n\n\n9․ No emoji\n--------------------------------------------------------------------------------\nGitHub like using cutesy graphics in their commit messages, and NPM do too, it'd\nseem. Submit a PR with an emoji *anywhere* and it'll get rejected - even if your\ncode is nothing short of brilliant.\n\nGit isn't Twitter. What you're seeing on GitHub is only a decorated rendition of\neach commit's actual content:\n\n![Figure 1](./img/figure-2.png)\n\nAlthough I guess it could always be worse:\n\n![Figure 2](./img/figure-3.png)\n\n\n\n10․ No commit prefixes\n--------------------------------------------------------------------------------\nThis ties in with the points raised in *\"How to write a commit message\"*, above.\nUse the imperative tone, leave out the leading `Prefix: Fix something`. Assuming\nyou're clear, direct and informative with your subject lines, grepping through a\n`--oneline` log shouldn't be a hassle.\n\n\n\n11․ Line length\n--------------------------------------------------------------------------------\n\n* Commit subjects:         \u003c= 69 (REQUIRED)\n* Commit bodies:           \u003c= 72 (REQUIRED)\n* Prose or documentation:  \u003c~ 80 (Encouraged, but not mandatory)\n* Anything else/code:      -- -- (Not fussed)\n\nI'm \"not fussed\" because none of my projects are expected to be worked on within\nwidth-challenged editing environments. If a future project is being written with\nutmost portability in mind (think ISO/Git-level), line length will be explicitly\nmentioned in `CONTRIBUTING.md`.\n\nUse your best judgement when determining how long is \"too long\". Things like big\nURLs and hairy regular expressions can't always be helped. They won't render the\nrest of the document unreadable if they're folded, either. Keeping documentation\nunder a character limit is more a matter of keeping diffs more readable - a typo\nfix on a 450-character long line really doesn't make perusing a revision history\nvery fun.\n\n(Anybody reading this file's source code should be advised that I DON'T expect a\nsimilar level of precision from contributions. That'd be kinda ridiculous).\n\nWhen keeping lines under a character limit, assume tabs to be 8-characters wide.\nThis is the default size assumed by virtually all terminal-like environments: if\nsomebody needs stuff kept within the 80-column boundary, you can probably assume\nthey're using a TTY with 8-character tab-stops. Even if you're wrong, most users\nwill have tab-sizes set to a smaller size like 4 or 2. Multics used 10-character\ntab-stops, but if that's an issue, please let me know. I want to be the first to\ntry your time machine.\n\n\n\n12․ Use traditional English spelling (\"British\" English)\n--------------------------------------------------------------------------------\nUnsurprisingly, many open source projects suffer from an unpredictable mix of US\nEnglish and traditional English (what the US call \"British\" English). I'm from a\nCommonwealth nation, and I was taught to use Standard English. Therefore, that's\nwhat I use when naming my identifiers (e.g., `class RGBColour`). I don't care if\nthe language's standard library uses US English - my projects use the spelling I\ngrew up with. And because I'm a pedantic prick, I'll enforce consistent language\nif I choose to. You mightn't like it. Tough shit.\n\nIf writing \"colour\" bothers you, spare a thought for those of us forced to write\n\"color\" because a language was authored that way. Then imagine what it'd be like\nto feel that every day of your life while doing something you enjoy.\n\n\n\nConclusion\n--------------------------------------------------------------------------------\nI'm used to working alone - I write code for code's sake, not because I'd expect\nmy projects to become group efforts. That doesn't mean I'm an arsehole: in fact,\nmost people would describe me as goofy and eccentric. There aren't many things I\ntake seriously, but code is one of them. Whether it's one of my own projects, or\nsomebody else's, I do what any coder worth their salt is expected to do - honour\nthe styleguide, and respect the decisions of the maintainers.\n\nSince I expect others will do the same, I've felt a rare moment of motivation to\npen something that I've never otherwise put in writing. If my projects DO become\ngroup efforts one day (or become maintained posthumously), maintainers will have\nsomething substantial to go by.\n\nOtherwise, I don't expect anybody to think anything more of these self-important\nramblings than any other styleguide they read and disagree with. Half the reason\nI wrote this was just an excuse to wrap shit to 80-characters without justifying\ntext. Yeah, I love lining things up, who you gonna call?\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falhadis%2Fcoding-style","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Falhadis%2Fcoding-style","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falhadis%2Fcoding-style/lists"}