Code Standards example.md

DO keep lines of code to 120 characters or less, unless a particular case is more readable when wider.
Use Microsoft's .NET naming guidelines, especially with…
- DO NOT capitalize prefixes or suffixes e.g. "Subcategory", not "SubCategory"
- DO use capital letters for two-letter acronyms, but NOT for three or more, nor for the special abbreviation "PPG"
- DO use PascalCase for properties on record types, as they are not merely parameters
AVOID prefixing properties and column names with the class/table name, e.g. use "Description" over "FundDescription"
- EXCEPTION: Never name a property or column just "Id" or "Type", e.g. should be "FundId" and "FundType"
DO set the indent width for HTML code only to two characters (with smart indent, insert spaces).
- This is in VS Pro > Tools > Options > Text Editor > HTML > Tabs
DO NOT let web controller classes depended directly on data-layer classes (which we call "Store"); instead they should depend on app service classes.
DO NOT use abbreviations in code or identifiers.
DO NOT add validation in the TradeLegacyBridgeService that was already validated in the Paragon service when consuming messages.
- DO NOT include data in messaging from Paragon that isn't necessary or that cannot be modified in Paragon. (The bridge can lookup data it needs.)
Database
- Use traditional SQL capitalization, e.g. "SELECT FundId FROM dbo.Fund"
- CONSIDER pushing multi-line string literals all the way to the left (i.e. column 1 with no indents), since this will allow more horizontal space.
- Left-align each new-line clause, indenting only for nesting; indent one level rather than trying to line up vertically, e.g.
  
  SELECT FundId, Description FROM dbo.Fund f JOIN dbo.FundType ft ON ft.FundTypeId = f.FundTypeId AND ft.FundTypeCode = f.FundTypeCode AND ft.FiscalYear = f.FiscalYear WHERE f.FundId < 1000 AND f.IsActive = 1;
- DO ensure all primary key columns appear at the beginning of the column list for all tables.
Asynchrony:
- When two or more asynchronous calls can run concurrently, DO start them then separately await them. No need for eager awaits, nor any need for Task.WhenAll in the normal case. Examples:
DO start then await when you need to:
```
  Task<Cat> task1 = FeedCat();
  Task<bool> task2 = SellHouse(); // will start immediately, while FeedCat is running
  Cat cat = await task1;     
  bool house = await task2; 
```
DO NOT await before you really want to:
```
  Cat cat = await FeedCat();
  bool house = await SellHouse(); // won't start till FeedCat is done
```
DO NOT use a redundant Task.WhenAll(…):
```
  Task<Cat> task1 = FeedCat();
  Task<bool> task2 = SellHouse(); // will start immediately, while FeedCat is running
  await Task.WhenAll(task1, task2); // redundant with below
  Cat cat = await task1;                    
  bool house = await task2;
```
- Remember that traditional event handlers must nearly always be synchronous, because the event invocation does not await.
  - If you want to invoke an asynchronous method on an event, you'll have to call .Wait() on the task in the lambda for the method.
  - An example is in ConsumingBackgroundService.cs in TradeFundingService.
  - Blazor EventCallbacks are not traditonal event handlers and therefore don't have this restriction.
CSS/HTML
- Our site.css should be the last CSS loaded, otherwise other styles (e.g. from Bootstrap) override our custom ones.
- Bootstrap rows: Never use class="row" unless it has only children of class="col".
- DO ensure that every element has a referent. DO…
  - Use a for="" attribute (pointing to the interactive element that it is for), OR…
  - Keep the interactive element(s) nested inside the label.
- If an interactive or content element is nested inside a element, DO put the label text proper inside a so that good styling can be applied to the label proper but not the interactive or content element.
- DO instead use element and DO NOT use a element if you have no interactive element to point to.

szalapski/Code Standards example.md