Revise assembly source code formatting specifications

README.md

@@ -47,13 +47,22 @@ If you wish to contribute, please fork the repository and submit pull requests.
 Also, assembly source code is formatted to the following specifications:
 
 - Spaces only (no tabs)
-- Labels start at column 1
-- Opcodes start at column 21
-- Operands start at column 31
-- Comments start at column 51
+- One space between opcode and operand, and operand and comments
+
+This ensures a consistent experience and efficient representation in the repository.
 
 Put [this file](https://github.com/nitros9project/nitros9/blob/main/scripts/pre-commit) in your .git/hooks folder to ensure that any source code you submit is automatically formatted.
 
+## Make commits meaningful
+
+When you commit your changes, please use standard Git message style. The first line of your message should be short but descriptive, telling viewers of the source code what you have changed in 50 characters or less. This is like a "Subject:" line in an email, and `git format-patch` actually uses it as one.
+
+If the change is not 100% self-explanatory, the first line should be followed by a blank line and a message (word wrapped at 72 or fewer characters) telling everyone _why_ you made your changes. Be descriptive, someone (perhaps even you) will someday need to understand what you had in mind when you wrote something, and the easier that is for them the better.
+
+Everything in each commit should be related to a single change, described in the message. For example, if you are documenting a source file and also optimizing it, those actions are separate even if they touch the same file. Document it first, then optimize; so that if you accidentally make a mistake in one change, we can use Git tools to revert just that change without having to detangle two of them.
+
+That doesn't mean you need to do _everything_ separately, though. It's possible for one change to touch many files and still be a single change. One example would be renaming an assembly language symbol-- something like that should definitely be done in every file that uses it, so that there's no window during which the build process is broken.
+
 # Coding Style Guidelines
 
 Here are some general coding guidelines for the project.
@@ -64,18 +73,18 @@ Having a comment on each line of assembly may seem excessive, but doing so keeps
 
 ## Make comments meaningful
 
-Take time to write clearly about what a line of code is doing. Avoid repeating the obvious, if possible.
+Take time to write clearly about what a line of code is doing. Avoid repeating the obvious.
 
 Instead of this:
 
 ```
-     clra        clear A
+ clra clear A
 ```
 
 do this:
 
 ```
-     clra        set the path to standard input
+ clra set the path to standard input
 ```      
 
 ## Write comments in lowercase and don't use punctuation
@@ -85,13 +94,13 @@ Comments may or may not be complete sentences; as such, dispense with the formal
 Instead of this:
 
 ```
-     ldb   #E$PNNF      Prepare the "pathname not found" error.
+ ldb #E$PNNF Prepare the "pathname not found" error.
 ```
 
 do this:
 
 ```
-     ldb   #E$PNNF      prepare the "pathname not found" error
+ ldb #E$PNNF prepare the "pathname not found" error
 ```      
 ## Use full words
 
@@ -100,15 +109,15 @@ Avoid abbreviations. Spelling out words increases the readability of the comment
 Instead of this:
 
 ```
-     pshs  d,x,y,u      push regs
-     leax  ,u           load path desc ptr in X
+ pshs d,x,y,u push regs
+ leax ,u load path desc ptr in X
 ```
 
 do this:
 
 ```
-     pshs  d,x,y,u      save the registers on the stack
-     leax  ,u           load the path descriptor pointer in X
+ pshs d,x,y,u save the registers on the stack
+ leax ,u load the path descriptor pointer in X
 ```
 
 ## Ensure an empty line is at the end of a source file
@@ -119,12 +128,12 @@ the input do not abandon any important information on the last line.
 Instead of this:
 
 ```
-     rts
+ rts
 ```
 
 do this:
 
 ```
-     rts
+ rts
 
 ```