- A PR is a conversation about code, not just a means to an end to add code to a repository
- A well written PR should be re viewable by a novice/junior programmer
- A PR is best when it is short, has a clear focus, and contains a clear commit history
- A developer should consider how a given commit will appear in a diff to those reviewing the code
- A dev team should have a 'social contract' that defines how they are going to communicate and what things they are going to care about as a team.
- A dev should strive to make other devs 'code switch' as little as possible by writing code that falls into an agreed upon standard deviation for the team.
- A feature branch merged into main, stage, or test environments should not negatively impact the applications ability to run correctly in any way
- Sub branches merged into feature branches don't need to ensure the application still runs correctly. Rather, they should be geared towards creating a productive 'conversation about code'.
- Especially if it aligns with a teams 'social contract', attention to detail should not be viewed as nit picking, but rather striving to maintain an understandable code-base for the team. (JW)
- Split off boilerplate additions into their own commit, if possible
- Provide examples when applicable in either the PR or the commit
- When cutting and pasting code from one place to another, have one commit be the cut and paste, while another commit includes any changes
- If there are some undesirable syntax patterns you come across while working that you'd like to update, lump them in a commit or even a few at the end. I like to append mine with #LNT, "Leave No Trace", which are a set of principles on how to act outdoors. One of those priciples is to "leave things cleaner than you found them".
- definition - an implicit agreement among the members of a society to cooperate for social benefits
- key takeaway - give up some individual preferences, for the sake of team preference/"greater good"
- definition - the practice of alternating between two or more languages or varieties of language in conversation
- programming lens - programmers commonly have their own flair when writing code; other programmers need to 'code switch' a little in order to read/review their code
- key takeaway - code switching can be taxing; if we all write code similarly enough we need to 'code switch' less, and that will preserve our brain's power for more effective review of each other's code
- definition - values within a range on either side of a mean value
- programming lens - there is a range of habits for writing 'readable code' for a given team, and the team should set that