{"id":24196573,"url":"https://github.com/dedis/coding","last_synced_at":"2025-09-21T21:31:55.204Z","repository":{"id":56012846,"uuid":"45896273","full_name":"dedis/Coding","owner":"dedis","description":"Scripts for coding and best practices","archived":false,"fork":false,"pushed_at":"2020-12-01T08:19:20.000Z","size":104,"stargazers_count":8,"open_issues_count":1,"forks_count":4,"subscribers_count":16,"default_branch":"master","last_synced_at":"2023-03-24T13:13:25.449Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dedis.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-11-10T07:50:35.000Z","updated_at":"2023-03-24T13:13:25.449Z","dependencies_parsed_at":"2022-08-15T11:20:52.292Z","dependency_job_id":null,"html_url":"https://github.com/dedis/Coding","commit_stats":null,"previous_names":[],"tags_count":null,"template":null,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dedis%2FCoding","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dedis%2FCoding/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dedis%2FCoding/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dedis%2FCoding/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dedis","download_url":"https://codeload.github.com/dedis/Coding/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":233798341,"owners_count":18731962,"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":[],"created_at":"2025-01-13T19:35:55.907Z","updated_at":"2025-09-21T21:31:54.844Z","avatar_url":"https://github.com/dedis.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Coding\n\nScripts for coding and best practices for the DeDiS-workgroup.\n\n## GitHub usage\n\nWe make use of Github's project: https://github.com/dedis/projects/1 and\ndefine the following columns:\n\n- Ready4Merge: pull-requests we think are ready to be merged. Please\nhave a regular look into this pipeline and comment. If two engineers\nother than the owner of the pull-request-owner agree to merge, it\nshould be done.\n- WIP: Work-In-Progress - what people are currently working on. It is\nOK to move things around between WIP and the following pipeline\n- TODO: Open issues that should be treated next.\n- BUG: Issues that make the project behave in a not-wanted way.\n- NeedDetails: Issues that are not detailed enough to work on them\nand need more explanation.\n\n### Branches\n\nAll work has to be done in branches. Per default, branches go off from\n`master`, which should always be in a functional state.\n\nThe branch-name should be one to three words, concatenated using underscores,\nfollowed by the number of the issue it solves.\nIf you work on a foreign branch, include the start of the foreign branch in\nyour branch.\n\nLet's say user 1 made a branch `add_platform_lxc_345` and you want to\nparticipate, you'll create a branch that goes off it with the name\n`add_platform_lxc_macosxfix_345` and do a pull request to the first branch,\n`add_platform_lxc_345`.\n\nThere are two scripts, [`gic`](#gid) and [`gid`](#gid), in the `bin`\ndirectory which make it a lot easier to handle a lot of long branch names\nand can save you a lot of typing.\n\n### Pull Requests and Issues\n\nWe now follow the github practice of having separate issues and pull\nrequests. Ideally this allows to have general discussions in the\nissues and more implementation-specific discussions in the pull request.\nIf a pull request is deleted, the general discussion is still available.\n\n### Assignees\n\nAn issue/pull-request with an assignee belongs to this person - he is\n responsible for it. Specially for a pull-request, this means:\n\n- only the assignee may add commits to this pull-request\n- only somebody else than the assignee may merge the pull-request\n\nIf somebody else wants to participate on a given pull-request, he can make a\n new branch off from this pull-request and continue the work therein:\n\n```\nPR1 with assignee1\n+- PR2 with assignee2\n```\n\nNow the assignee1 has to merge the PR2 into his PR1, but only somebody else\n than assignee1 can merge the PR1 back into the development-branch.\n\n### Commits and push\n\nThe general rule is that for each commit, all tests should pass. This is not\n  a hard rule, but it should be used whenever possible.\n\n### Merge to master\n\nBefore merging into master, all tests MUST pass. This can be enforced by\nusing the ```.git/hooks/pre-push``` hook provided in this repository.\nThen you have to pass code-review by one or two other developers, which will\ncomment your code and ask for changes (see for example \n[google code review practices](https://google.github.io/eng-practices/review/reviewer/). \nOnly once at least one other\ndeveloper is happy with your branch can he merge it.\n\nIt is good practice to do a `squash` when merging and adding all important\ninformation about the merge in the squash-comment.\n\n### Travis\n\nA travis-script checks the go-formatting and all tests. Before a merge is done,\nTravis must be OK.\n\n### Coveralls\n\nIn every PR the code coverage shall not decrease (+/-0.5% is OK though). \nWe aim for ~100% and have 80% as lower boundary. Code containing only `func main`\nand not much more is OK if it is tested by integration tests and manually instead\nof unit tests (for these few packages may have lower code coverage).\n\n### Go-imports and git pre-push\n\nIf you have troubles using goimports in your editor, please use the pre-push hook\nin this directory for git. If you alread installed the 'bin'-directory with\n`add_path_to_mac`, you can just call `add_hooks`. Now everytime before your\nchanges get pushed, `goimport` renices all your files.\n\n## Comments\n\nTwo important links regarding comments:\n- [Godoc: documenting Go code](http://blog.golang.org/godoc-documenting-go-code)\n- [Effective Go](https://golang.org/doc/effective_go.html)\n\nSome important notes about what to comment:\n\n- every function should be commented\n- every package needs a comment in the `packagename.go`-file (arbitrarily\n set by myself)\n\nCommenting-language is English, if you're not sure, don't hesitate to take\nsome time off in Google or wherever to increase your knowledge of English!\n\nPlease turn your auto-correction on and fix words that are marked as wrong,\nexcept function- and variable-names that aren't English words.\n\n## Line-width\n\nThe standard line-width is 80 characters and this is a hard limit.\n\n## Scripts\n\nTwo scripts are provided for more easy switching and cleaning up between\nbranches.\n\n### gic\n\nThe bash script [`gic`](bin/gic) stands for git-checkout. If you call it\nwithout any arguments, it will output a list of all branches that are checked\nout, together with a number in front. This lets you easily change between\nbranches.\n\nNew branches that have never been checked out will come in the second part of\nthe list and can be checked out the same way.\n\n### gid\n\nThe script [`gid`](bin/gic) will delete a local branch to make place for new\nbranches. Called without arguments, it will show a list of all branches\navailable for deletion, called with a number, it will try to delete that\nbranch. This can fail if the branch hasn't been pushed.\n\n## Debug-levels\n\nWe're using the `cothority/lib/dbg`-library for debug-output which offers a \nnumerical debug-level. The debug-levels represent:\n  \n  * 1 - important information to follow the correct working of a simulation\n  * 2 - additional information which doesn't spam the screen when running with \n     more than 20 hosts\n  * 3 - debugging information for following the code-path, only useful for up to\n     20 hosts\n  * 4 - information for verbose output in testing\n  * 5 - not really used\n\n### Evolution of debug-levels\n\nWhile writing fresh code, the new functions will have lower debug-levels, as they\nwill most probably influence a lot of what is being coded and where bugs reside.\nAs the functions mature, the debug-levels can be increased, as most often they\ndon't indicate anything interesting anymore.\n\n### Debugging with LLvl and Print\n\nIf a given output is interesting for debugging regardless of the level, the\n`dbg.Lvl` can be changed to `dbg.LLvl` which will always print the information.\n\nThis is useful if you are debugging something and want to follow a certain path\nthat has only high debug-levels.\n\nFor fast dumping of variables one can also use `log.Print` which is easy to find\nand remove once the debugging-session is done.\n\n### Format-functions in debug\n\nEvery debug-function has also a -*f*-function: `Lvl1` and `Lvlf1`, `Lvl2` and \n`Lvlf2`..., `Print` and `Printf`, `Fatal` and `Fatalf`, `Error` and `Errorf`.\n\nThe format-functions work like `fmt.Printf`.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdedis%2Fcoding","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdedis%2Fcoding","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdedis%2Fcoding/lists"}