Val set = Set(new Date, new Date, new Date) Package names should not be mentioned outside of import declarations. Trailing spaces serve no use and benefit no one.įiles that don't end in newlines can wreak havoc on certain Linux tools. Tabs are obnoxious and cause the code to be displayed differently on different machines. ReasonĢ-space indentation is the Scala standard way. Curly braces should be separated from the code within them by a one-space gap, to give the visually busy braces “breathing room”." ExceptionsĪdding extra spaces for your indentation in order to make code line up is perfectly acceptable-encouraged, even. ( git diff can easily detect many of these errors.)įrom the official Scala style documentation: "There should be no space between parentheses and the code they contain. Ensure that your files all end in newlines. The get around this problem in Git, simply perform your diff or show or whatever with the -w flag to not show whitespace changes. One of the most common complaints about code alignment is that it makes diffs unreadable. This is not something that is unique to code how pleased would you be if each cell in a spreadsheet had a unique size? How easy would that be to read? Very often, code takes the form of applying very similar operation operations to multiple pieces of partially-related data, and it's very convenient to be able to look at one row and one column of a block of code and immediately know what the entire block does. When the common parts of a block of code line up, it is much easier to read. 20+ spaces), probably don't worry about it. If doing this would require padding the code with a large block of spaces (e.g. "When not awkward to do so" is the operative phrase. When not awkward to do so, code should be padded with extra spaces to make clear the relations of parts across lines. The era of widescreen monitors is a wondrous thing. Lines are limited to 120 characters in length. If commit A doesn't pass the tests, but commit B does, and I revert commit B, I likely now have a test-failing repo on my hands, and I probably don't know why they're failing).Ĭommit messages are expected to fit within 72 characters, with a suggestion of keeping it to around 50 characters, because that's simply the Git standard. compiling tests passing) because it makes bisecting a lot easier, and also for the same reasons given above for having small commits (e.g. They are also easier to understand when looking through old version history and trying to understand what was being done and why.Ĭommits are expected to keep the repo in a good state (i.e. Reasonīite-sized commits are easy to revert and cherry-pick. However, do make sure to rebase the WIP branch to clean up the history before bringing it over to the main branch. ExceptionsĬlearly, these rules don't apply to commits on work-in-progress (WIP) branches (neither local nor remote). explanation of caveats, personal woes, or contracts made with Satan) should be placed in the area below the main commit message. Any information you decide to include that isn't entirely concerned in describing what the commit does (e.g. Occasional lapses in this are permissible, but don't make a habit of it.Ĭommit messages should be descriptive and fit within 72 characters (the Git standard). Commits that end up on the main branch of a GitHub repo are each expected to compile and pass the tests. A commit should neither contain huge swathes of unrelated changes nor a small set of changes that cannot stand alone. In version control (Git), aim to make your commits small, orthogonal chunks of functionality. If you can't find any advice about a particular something anywhere, do it your way and see what happens. If you absolutely must write new Java, try to glean the code style from the plethora of existing Java files and emulate it.įor anything else that you can't find the answer to here, please see the Scala Documentation site for their suggestions. Ideally, you should not be writing new Java code. This document does not concern itself with Java code style.
0 kommentar(er)
