{"id":17067730,"url":"https://github.com/justinamiller/coding-standards","last_synced_at":"2025-06-15T04:41:22.517Z","repository":{"id":143244211,"uuid":"93628327","full_name":"justinamiller/Coding-Standards","owner":"justinamiller","description":"Coding Guidelines for C#","archived":false,"fork":false,"pushed_at":"2019-04-29T14:11:51.000Z","size":51,"stargazers_count":147,"open_issues_count":1,"forks_count":28,"subscribers_count":7,"default_branch":"master","last_synced_at":"2025-04-12T18:13:55.113Z","etag":null,"topics":["architecture","c-sharp","codeguide","coding-conventions","coding-standards","coding-style","coding-styles","consistency","guide","guidelines","naming-conventions","netcore","netframework","netstandard"],"latest_commit_sha":null,"homepage":"","language":"C#","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/justinamiller.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2017-06-07T11:34:11.000Z","updated_at":"2025-03-14T12:03:49.000Z","dependencies_parsed_at":"2023-04-10T09:01:28.320Z","dependency_job_id":null,"html_url":"https://github.com/justinamiller/Coding-Standards","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/justinamiller%2FCoding-Standards","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/justinamiller%2FCoding-Standards/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/justinamiller%2FCoding-Standards/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/justinamiller%2FCoding-Standards/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/justinamiller","download_url":"https://codeload.github.com/justinamiller/Coding-Standards/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248610336,"owners_count":21132920,"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":["architecture","c-sharp","codeguide","coding-conventions","coding-standards","coding-style","coding-styles","consistency","guide","guidelines","naming-conventions","netcore","netframework","netstandard"],"created_at":"2024-10-14T11:11:31.027Z","updated_at":"2025-04-12T18:14:04.835Z","avatar_url":"https://github.com/justinamiller.png","language":"C#","readme":"# Coding Guidelines for C#\n\n## Introduction\nThis document describes rules and recommendations for developing applications and class libraries using the C#\nLanguage. The goal is to define guidelines to enforce consistent style and formatting and help developers avoid common\npitfalls and mistakes.\nSpecifically, this document covers Naming Conventions, Coding Style, Language Usage, and Object Model Design. \n\n### Scope\nThis document only applies to the C# Language and the .NET Framework Common Type System(CTS) it implements.\nAlthough the C# language is implemented alongside the .NET Framework, this document does not address usage of\n.NET Framework class libraries. However, common patterns and problems related to C#’s usage of the .NET Framework\nare addressed in a limited fashion.\nEven though standards for curly-braces ({ or }) and white space(tabs vs. spaces) are always controversial, these topics\nare addressed here to ensure greater consistency and maintainability of source code. \n\n### Terminology \u0026 Definitions\nThe following terminology is referenced throughout this document:\n\n#### Access Modifier\nC# keywords public, protected, internal, and private declare the allowed code-accessibility of types\nand their members. Although default access modifiers vary, classes and most other members use the default\nof private. Notable exceptions are interfaces and enums which both default to public.\n\n#### Camel Case\nA word with the first letter lowercase, and the first letter of each subsequent word-part capitalized.\n Example: customerName\n \n#### Common Type System\nThe .NET Framework common type system (CTS) defines how types are declared, used, and managed. All\nnative C# types are based upon the CTS to ensure support for cross-language integration.\n\n#### Identifier\nA developer defined token used to uniquely name a declared object or object instance.\n Example: \n ```\n public class MyClassName MyClassNameIdentifier Identifier { … }\n ```\n \n#### Magic Number\nAny numeric literal used within an expression (or to initialize a variable) that does not have an obvious or wellknown\nmeaning. This usually excludes the integers 0 or 1 and any other numeric equivalent precision that\nevaluates as zero.\n\n#### Pascal Case\nA word with the first letter capitalized, and the first letter of each subsequent word-part capitalized.\n Example: CustomerName\n\n#### Premature Generalization\nAs it applies to object model design; this is the act of creating abstractions within an object model not based\nupon concrete requirements or a known future need for the abstraction. In simplest terms: “Abstraction for\nthe sake of Abstraction.” \n\n\n### Naming Conventions Quick Guide\n“c” = camelCase\n“P” = PascalCase\n“_” = Prefix with _Underscore\n“x” = Not Applicable.\n\n|Identifier | Public | Protected | Internal | Private | Notes |\n|-----------|--------|-----------|----------|---------|-------|\n|Project File | P | x | x | x | Match Assembly \u0026 Namespace. |\n|Source File | P | x | x | x | Match contained class. |\n|Other Files | P | x | x | x | Apply where possible. |\n|Namespace | P | x | x | x | Partial Project/Assembly match. |\n|Class or Struct | P | P | P | P | Add suffix of subclass. |\n|Interface | P | P | P | P | Prefix with a capital I. |\n|Generic Class | P | P | P | P | Use T or K as Type identifier. |\n|Method | P | P | P | P | Use a Verb or Verb-Object pair. |\n|Property | P | P | P | P | Do not prefix with Get or Set. |\n|Field | P | P | P | _c | Only use Private fields. No Hungarian Notation! |\n|Constant | P | P | P | _c | |\n|Static Field | P | P | P | _c | Only use Private fields. |\n|Enum | P | P | P | P | Options are also PascalCase. |\n|Delegate | P | P | P | P | |\n|Event | P | P | P | P | |\n|Inline Variable | x | x | x | c | Avoid single-character and enumerated names. |\n|Parameter | x | x | x | c | | \n\n### Coding Style\n| Code | Style |\n|------|-------|\n|Source Files | One Namespace per file and one class per file. |\n|Curly Braces | On new line. Always use braces when optional. |\n|Indention | Use tabs with size of 4. |\n|Comments | Use // or /// but not /* … */ and do not flowerbox. |\n|Variables | One variable per declaration. |\n|Native Data Types | Use built-in C# native data types vs .NET CTS types. (Use int NOT Int32) |\n|Enums | Avoid changing default type. |\n|Generics | Prefer Generic Types over standard or strong-typed classes. |\n|Properties | Never prefix with Get or Set. |\n|Methods | Use a maximum of 7 parameters. |\n|base and this | Use only in constructors or within an override. |\n|Ternary conditions | Avoid complex conditions. |\n|foreach statements | Do not modify enumerated items within a foreach statement. |\n|Conditionals | Avoid evaluating Boolean conditions against true or false. No embedded assignment. Avoid embedded method invocation. |\n|Exceptions | Do not use exceptions for flow control. Use throw; not throw e; when re-throwing. Only catch what you can handle. Use validation to avoid exceptions. Derive from Execption not ApplicationException. |\n|Events | Always check for null before invoking. |\n|Locking | Use lock() not Monitor.Enter(). Do not lock on an object type or “this”. Do lock on private objects.|\n|Dispose() \u0026 Close() | Always invoke them if offered, declare where needed. |\n|Finalizers | Avoid. Use the C# Destructors. Do not create Finalize() method. |\n|AssemblyVersion | Increment manually. |\n|ComVisibleAttribute | Set to false for all assemblies. |\n\n## Naming Conventions\nConsistency is the key to maintainable code. This statement is most true for naming your projects, source files, and\nidentifiers including Fields, Variables, Properties, Methods, Parameters, Classes, Interfaces, and Namespaces.\n### General Guidelines\n1. Always use Camel Case or Pascal Case names.\n2. Avoid ALL CAPS and all lowercase names. Single lowercase words or letters are acceptable.\n3. Do not create declarations of the same type (namespace, class, method, property, field, or parameter) and\naccess modifier (protected, public, private, internal) that vary only by capitalization.\n4. Do not use names that begin with a numeric character.\n5. Do add numeric suffixes to identifier names.\n6. Always choose meaningful and specific names.\n7. Always err on the side of verbosity not terseness.\n8. Variables and Properties should describe an entity not the type or size.\n9. Do not use Hungarian Notation!\nExample: strName or iCount\n10. Avoid using abbreviations unless the full name is excessive.\n11. Avoid abbreviations longer than 5 characters.\n12. Any Abbreviations must be widely known and accepted.\n13. Use uppercase for two-letter abbreviations, and Pascal Case for longer abbreviations.\n14. Do not use C# reserved words as names.\n15. Avoid naming conflicts with existing .NET Framework namespaces, or types.\n16. Avoid adding redundant or meaningless prefixes and suffixes to identifiers\nExample:\n```\n// Bad!\npublic enum ColorsEnum {…}\npublic class CVehicle {…}\npublic struct RectangleStruct {…}\n```\n17. Do not include the parent class name within a property name.\nExample: \n```\nCustomer.Name NOT Customer.CustomerName\n```\n18. Try to prefix Boolean variables and properties with “Can”, “Is” or “Has”.\n19. Append computational qualifiers to variable names like Average, Count, Sum, Min, and Max where\nappropriate.\n20. When defining a root namespace, use a Product, Company, or Developer Name as the root. Example:\n```\nMy.StringUtilities\n```\n\n### Name Usage \u0026 Syntax\n|Identifier | Naming Convention |\n|-----------|-------------------|\n|Project File | Pascal Case. Always match Assembly Name \u0026 Root Namespace. Example: ``` My.Web.csproj -\u003e My.Web.dll -\u003e namespace My.Web ``` |\n|Source File | Pascal Case. Always match Class name and file name. Avoid including more than one Class, Enum (global), or Delegate (global) per file. Use a descriptive file name when containing multiple Class, Enum, or Delegates. Example: ``` MyClass.cs =\u003e public class MyClass  {…} ```|\n|Resource or Embedded File | Try to use Pascal Case. Use a name describing the file contents. |\n|Namespace | Pascal Case. Try to partially match Project/Assembly Name. Example: ``` namespace My.Web {…} ```\n|Class or Struct | Pascal Case. Use a noun or noun phrase for class name. Add an appropriate class-suffix when sub-classing another type when possible. Examples: ``` private class MyClass {…} internal class SpecializedAttribute : Attribute {…} public class CustomerCollection : CollectionBase {…} public class CustomEventArgs : EventArgs {…} private struct ApplicationSettings {…} ``` |\n|Interface | Pascal Case. Always prefix interface name with capital “I”. Example: ``` interface ICustomer {…} ``` |\n| Generic Class \u0026 Generic Parameter Type |Always use a single capital letter, such as T or K. Example: ``` public class FifoStack\u003cT\u003e { public void Push(\u003cT\u003e obj) {…} public \u003cT\u003e Pop() {…} } ``` |\n|Method | Pascal Case. Try to use a Verb or Verb-Object pair. Example: ``` public void Execute() {…} private string GetAssemblyVersion(Assembly target) {…} ``` |\n|Property | Pascal Case. Property name should represent the entity it returns. Never prefix property names with “Get” or “Set”. Example: ```public string Name { get{…} set{…} } ``` |\n|Field (Public, Protected, or Internal) | Pascal Case. Avoid using non-private Fields! Use Properties instead. Example: ``` public string Name; protected IList InnerList; ``` |\n|Field (Private) | Camel Case and prefix with a single underscore (_) character. Example: ``` private string _name; ``` |\n|Constant or Static Field | Treat like a Field. Choose appropriate Field access-modifier above. |\n|Enum | Pascal Case (both the Type and the Options). Add the FlagsAttribute to bit-mask multiple options. Example: ``` public enum CustomerTypes { Consumer, Commercial } ``` |\n|Delegate or Event | Treat as a Field. Choose appropriate Field access-modifier above. Example: ``` public event EventHandler LoadPlugin; ``` |\n|Variable (inline) | Camel Case. Avoid using single characters like “x” or “y” except in FOR loops. Avoid enumerating variable names like text1, text2, text3 etc. |\n|Parameter | Camel Case. Example: ``` public void Execute(string commandText, int iterations) {…} ``` |\n\n\n## Coding Style\nCoding style causes the most inconsistency and controversy between developers. Each developer has a preference, and\nrarely are two the same. However, consistent layout, format, and organization are key to creating maintainable code.\nThe following sections describe the preferred way to implement C# source code in order to create readable, clear, and\nconsistent code that is easy to understand and maintain.\n### Formatting\n1. Never declare more than 1 namespace per file.\n2. Avoid putting multiple classes in a single file.\n3. Always place curly braces ({ and }) on a new line.\n4. Always use curly braces ({ and }) in conditional statements.\n5. Always use a Tab \u0026 Indention size of 4.\n6. Declare each variable independently – not in the same statement.\n7. Place namespace “using” statements together at the top of file. Group .NET namespaces above custom\nnamespaces.\n8. Group internal class implementation by type in the following order:\na. Member variables.\nb. Constructors \u0026 Finalizers.\nc. Nested Enums, Structs, and Classes.\nd. Properties\ne. Methods\n9. Sequence declarations within type groups based upon access modifier and visibility:\na. Public\nb. Protected\nc. Internal\nd. Private\n10. Segregate interface Implementation by using #region statements.\n11. Append folder-name to namespace for source files within sub-folders.\n12. Recursively indent all code blocks contained within braces.\n13. Use white space (CR/LF, Tabs, etc) liberally to separate and organize code.\n14. Only declare related attribute declarations on a single line, otherwise stack each attribute as a separate\ndeclaration.\nExample:\n```\n// Bad!\n[Attrbute1, Attrbute2, Attrbute3]\npublic class MyClass\n{…}\n// Good!\n[Attrbute1, RelatedAttribute2]\n[Attrbute3]\n[Attrbute4]\npublic class MyClass\n{…}\n```\n15. Place Assembly scope attribute declarations on a separate line.\n16. Place Type scope attribute declarations on a separate line.\n17. Place Method scope attribute declarations on a separate line.\n18. Place Member scope attribute declarations on a separate line.\n19. Place Parameter attribute declarations inline with the parameter.\n20. If in doubt, always err on the side of clarity and consistency. \n\n### Code Commenting\n21. All comments should be written in the same language, be grammatically correct, and contain appropriate\npunctuation.\n22. Use // or /// but never /* … */\n23. Do not “flowerbox” comment blocks.\nExample:\n```\n // ***************************************\n // Comment block\n // ***************************************\n ```\n24. Use inline-comments to explain assumptions, known issues, and algorithm insights.\n25. Do not use inline-comments to explain obvious code. Well written code is self documenting.\n26. Only use comments for bad code to say “fix this code” – otherwise remove, or rewrite the code!\n27. Include comments using Task-List keyword flags to allow comment-filtering.\nExample:\n```\n// TODO: Place Database Code Here\n// UNDONE: Removed P\\Invoke Call due to errors\n// HACK: Temporary fix until able to refactor\n```\n28. Always apply C# comment-blocks (///) to public, protected, and internal declarations.\n29. Only use C# comment-blocks for documenting the API.\n30. Always include \u003csummary\u003e comments. Include `\u003cparam\u003e`, `\u003creturn\u003e`, and `\u003cexception\u003e` comment\nsections where applicable.\n31. Include `\u003csee cref=\"\"/\u003e` and `\u003cseeAlso cref=\"\"/\u003e` where possible.\n32. Always add CDATA tags to comments containing code and other embedded markup in order to avoid\nencoding issues.\nExample:\n```\n/// \u003cexample\u003e\n/// Add the following key to the “appSettings” section of your config:\n/// \u003ccode\u003e\u003c![CDATA[\n/// \u003cconfiguration\u003e\n/// \u003cappSettings\u003e\n/// \u003cadd key=\"mySetting\" value=\"myValue\"/\u003e\n/// \u003c/appSettings\u003e\n/// \u003c/configuration\u003e\n/// ]]\u003e\u003c/code\u003e \u003e\n/// \u003c/example\u003e \n```\n\n## Language Usage\n### General\n1. Do not omit access modifiers. Explicitly declare all identifiers with the appropriate access modifier instead of\nallowing the default.\nExample:\n```\n// Bad!\nVoid WriteEvent(string message)\n{…}\n// Good!\nprivate Void WriteEvent(string message)\n{…}\n```\n2. Do not use the default (“1.0.*”) versioning scheme. Increment the AssemblyVersionAttribute value\nmanually.\n3. Set the ComVisibleAttribute to false for all assemblies.\n4. Only selectively enable the ComVisibleAttribute for individual classes when needed.\nExample:\n```\n[assembly: ComVisible(false)]\n[ComVisible(true)]\npublic MyClass\n{…}\n```\n5. Consider factoring classes containing unsafe code blocks into a separate assembly.\n6. Avoid mutual references between assemblies.\n4.2 Variables \u0026 Types\n7. Try to initialize variables where you declare them.\n8. Always choose the simplest data type, list, or object required.\n9. Always use the built-in C# data type aliases, not the .NET common type system (CTS).\nExample:\n```\nshort NOT System.Int16\nint NOT System.Int32\nlong NOT System.Int64\nstring NOT System.String\n```\n10. Only declare member variables as private. Use properties to provide access to them with public,\nprotected, or internal access modifiers.\n11. Try to use int for any non-fractional numeric values that will fit the int datatype - even variables for nonnegative\nnumbers.\n12. Only use long for variables potentially containing values too large for an int.\n13. Try to use double for fractional numbers to ensure decimal precision in calculations.\n14. Only use float for fractional numbers that will not fit double or decimal.\n15. Avoid using float unless you fully understand the implications upon any calculations.\n16. Try to use decimal when fractional numbers must be rounded to a fixed precision for calculations. Typically\nthis will involve money.\n17. Avoid using sbyte, short, uint, and ulong unless it is for interop (P/Invoke) with native libraries. \n Avoid specifying the type for an enum - use the default of int unless you have an explicit need for long (very\nuncommon).\n19. Avoid using inline numeric literals (magic numbers). Instead, use a Constant or Enum.\n20. Avoid declaring string literals inline. Instead use Resources, Constants, Configuration Files, Registry or other\ndata sources.\n21. Declare readonly or static readonly variables instead of constants for complex types.\n22. Only declare constants for simple types.\n23. Avoid direct casts. Instead, use the “as” operator and check for null.\nExample:\n```\nobject dataObject = LoadData();\nDataSet ds = dataObject as DataSet;\nif(ds != null)\n{…}\n```\n24. Always prefer C# Generic collection types over standard or strong-typed collections.\n25. Always explicitly initialize arrays of reference types using a for loop.\n26. Avoid boxing and unboxing value types.\nExample:\n```\nint count = 1;\nobject refCount = count; // Implicitly boxed.\nint newCount = (int)refCount; // Explicitly unboxed.\n```\n27. Floating point values should include at least one digit before the decimal place and one after.\nExample: totalPercent = 0.05;\n28. Try to use the “@” prefix for string literals instead of escaped strings.\n29. Prefer String.Format() or StringBuilder over string concatenation.\n30. Never concatenate strings inside a loop.\n31. Do not compare strings to String.Empty or “” to check for empty strings. Instead, compare by using\nString.Length == 0.\n32. Avoid hidden string allocations within a loop. Use String.Compare() for case-sensitive \nExample (ToLower() create a temp string)\n\n```\n// Bad!\nint id = -1;\nstring name = “john doe”;\nfor(int i=0; i \u003c customerList.Count; i++)\n{\nif(customerList[i].Name.ToLower() ToLower() ToLower() == name)\n {\n id = customerList[i].ID;\n }\n}\n// Good!\nint id = -1;\nstring name = “john doe”;\nfor(int i=0; i \u003c customerList.Count; i++)\n{\n// The “ignoreCase = true” argument performs a\n // case-insensitive compare without new allocation.\nif(String.Compare String.Compare String.Compare(customerList[i].Name, name, true)== 0)\n {\n id = customerList[i].ID;\n }\n}\n```\n\n### Flow Control\n33. Avoid invoking methods within a conditional expression.\n34. Avoid creating recursive methods. Use loops or nested loops instead.\n35. Avoid using foreach to iterate over immutable value-type collections. E.g. String arrays.\n36. Do not modify enumerated items within a foreach statement.\n37. Use the ternary conditional operator only for trivial conditions. Avoid complex or compound ternary operations.\nExample: int result = isValid ? 9 : 4;\n38. Avoid evaluating Boolean conditions against true or false.\nExample:\n```\n// Bad!\nif (isValid == true)\n{…}\n// Good!\nif (isValid)\n{…}\n```\n39. Avoid assignment within conditional statements.\nExample: if((i=2)==2) {…}\n40. Avoid compound conditional expressions – use Boolean variables to split parts into multiple manageable\nexpressions.\nExample:\n```\n// Bad!\nif (((value \u003e _highScore) \u0026\u0026 (value != _highScore)) \u0026\u0026 (value \u003c _maxScore))\n{…}\n// Good!\nisHighScore = (value \u003e= _highScore);\nisTiedHigh = (value == _highScore);\nisValid = (value \u003c _maxValue);\nif ((isHighScore \u0026\u0026 ! isTiedHigh) \u0026\u0026 isValid)\n{…}\n```\n41. Avoid explicit Boolean tests in conditionals.\n```\nExample:\n// Bad!\nif(IsValid == true)\n{…};\n// Good!\nif(IsValid)\n{…}\n```\n42. Only use switch/case statements for simple operations with parallel conditional logic.\n43. Prefer nested if/else over switch/case for short conditional sequences and complex conditions.\n44. Prefer polymorphism over switch/case to encapsulate and delegate complex operations.\n\n### Exceptions\n45. Do not use try/catch blocks for flow-control.\n46. Only catch exceptions that you can handle.\n47. Never declare an empty catch block.\n48. Avoid nesting a try/catch within a catch block.\n49. Always catch the most derived exception via exception filters.\n50. Order exception filters from most to least derived exception type.\n51. Avoid re-throwing an exception. Allow it to bubble-up instead.\n52. If re-throwing an exception, preserve the original call stack by omitting the exception argument from the throw\nstatement.\nExample:\n```\n// Bad!\ncatch(Exception ex)\n{\n Log(ex);\nthrow ex;\n}\n// Good!\ncatch(Exception)\n{\n Log(ex);\nthrow;\n}\n```\n53. Only use the finally block to release resources from a try statement. \n54. Always use validation to avoid exceptions.\nExample:\n```\n// Bad!\ntry\n{\n conn.Close();\n}\nCatch(Exception ex)\n{\n // handle exception if already closed!\n}\n// Good!\nif(conn.State != ConnectionState.Closed)\n{\n conn.Close();\n}\n```\n55. Always set the innerException property on thrown exceptions so the exception chain \u0026 call stack are\nmaintained.\n56. Avoid defining custom exception classes. Use existing exception classes instead.\n57. When a custom exception is required;\na. Always derive from Exception not ApplicationException.\nb. Always suffix exception class names with the word “Exception”.\nc. Always add the SerializableAttribute to exception classes.\nd. Always implement the standard “Exception Constructor Pattern”:\npublic MyCustomException ();\npublic MyCustomException (string message);\npublic MyCustomException (string message, Exception innerException);\ne. Always implement the deserialization constructor:\nprotected MyCustomException(SerializationInfo info, StreamingContext contxt);\n58. Always set the appropriate HResult value on custom exception classes.\n(Note: the ApplicationException HResult = -2146232832)\n59. When defining custom exception classes that contain additional properties:\na. Always override the Message property, ToString() method and the implicit operator string\nto include custom property values.\nb. Always modify the deserialization constructor to retrieve custom property values.\nc. Always override the GetObjectData(…) method to add custom properties to the serialization collection.\nExample:\n```\npublic override void GetObjectData(SerializationInfo info,\n StreamingContext context)\n{\n base.GetObjectData (info, context);\ninfo.AddValue(\"MyValue\", _myValue);\n} \n```\n\n### Events, Delegates, \u0026 Threading\n60. Always check Event \u0026 Delegate instances for null before invoking.\n61. Use the default EventHandler and EventArgs for most simple events.\n62. Always derive a custom EventArgs class to provide additional data.\n63. Use the existing CancelEventArgs class to allow the event subscriber to control events.\n64. Always use the “lock” keyword instead of the Monitor type.\n65. Only lock on a private or private static object.\nExample: lock(myVariable);\n66. Avoid locking on a Type.\nExample: \n```\nlock(typeof(MyClass));\n```\n67. Avoid locking on the current object instance.\nExample: \n```\nlock(this); \n```\n### Object Composition\n68. Always declare types explicitly within a namespace. Do not use the default “{global}” namespace.\n69. Avoid overuse of the public access modifier. Typically fewer than 10% of your types and members will be\npart of a public API, unless you are writing a class library.\n70. Consider using internal or private access modifiers for types and members unless you intend to support\nthem as part of a public API.\n71. Never use the protected access modifier within sealed classes unless overriding a protected member of\nan inherited type.\n72. Avoid declaring methods with more than 5 parameters. Consider refactoring this code.\n73. Try to replace large parameter-sets (\u003e than 5 parameters) with one or more class or struct parameters –\nespecially when used in multiple method signatures.\n74. Do not use the “new” keyword on method and property declarations to hide members of a derived type.\n75. Only use the “base” keyword when invoking a base class constructor or base implementation within an\noverride.\n76. Consider using method overloading instead of the params attribute (but be careful not to break CLS\nCompliance of your API’s).\n77. Always validate an enumeration variable or parameter value before consuming it. They may contain any value\nthat the underlying Enum type (default int) supports.\nExample: Example\n```\npublic void Test(BookCategory cat)\n{\nif (Enum.IsDefined(typeof(BookCategory), cat))\n {…}\n}\n```\n78. Consider overriding Equals() on a struct.\n79. Always override the Equality Operator (==) when overriding the Equals() method.\n80. Always override the String Implicit Operator when overriding the ToString() method.\n81. Always call Close() or Dispose() on classes that offer it.\n82. Wrap instantiation of IDisposable objects with a “using” statement to ensure that Dispose() is\nautomatically called.\nExample:\n```\nusing(SqlConnection cn = new SqlConnection(_connectionString))\n{…}\n```\n83. Always implement the IDisposable interface \u0026 pattern on classes referencing external resources.\nExample: (shown with optional Finalizer)\n```\npublic void Dispose()\n{\n Dispose(true);\n GC.SuppressFinalize(this);\n}\nprotected virtual void Dispose(bool disposing)\n{\n if (disposing)\n {\n // Free other state (managed objects).\n }\n // Free your own state (unmanaged objects).\n // Set large fields to null.\n}\n// C# finalizer. (optional)\n~Base()\n{\n // Simply call Dispose(false).\n Dispose (false);\n}\n```\n84. Avoid implementing a Finalizer.\nNever define a Finalize() method as a finalizer. Instead use the C# destructor syntax.\nExample\n```\n// Good\n~MyClass {…}\n// Bad\nvoid Finalize(){…}\n```\n\n## Object Model \u0026 API Design\n1. Always prefer aggregation over inheritance.\n2. Avoid “Premature Generalization”. Create abstractions only when the intent is understood.\n3. Do the simplest thing that works, then refactor when necessary.\n4. Always make object-behavior transparent to API consumers.\n5. Avoid unexpected side-affects when properties, methods, and constructors are invoked.\n6. Always separate presentation layer from business logic.\n7. Always prefer interfaces over abstract classes.\n8. Try to include the design-pattern names such as “Bridge”, “Adapter”, or “Factory” as a suffix to class names\nwhere appropriate.\n9. Only make members virtual if they are designed and tested for extensibility.\n10. Refactor often! \n\n\n## Redundancy\n**Minimize redundant code**\n1. If you repeat the same code two or more times, find a way to remove the redundant code so that it appears only once. For example, place it into a helper function that is called from both places. If the repeated code is nearly but not entirely the same, try making your helper function accept a parameter to represent the differing part.\n````\n// bad\nfoo();\nx = 10;\ny++;\n...\n\nfoo();\nx = 15;\ny++;\n\n// good\nhelper(10);\nhelper(15);\n...\n\nvoid helper(int newX) {\n    foo();\n    x = newX;\n    y++;\n}\n````\n**if/else factoring**\n2. Move common code out of if/else statements so that it is not repeated.\n````\n// bad\nif (x \u003c y) {\n    foo();\n    x++;\n    Console.Write(\"hi\");\n} else {\n    foo();\n    y++;\n   Console.Write(\"hi\");\n}\n\n// good\nfoo();\nif (x \u003c y) {\n    x++;\n} else {\n    y++;\n}\nConsole.Write(\"hi\");\n````\n**Function structure**\n3. If you have a single function that is very long, break it apart into smaller sub-functions. The definition of \"very long\" is vague, but let's say a function longer than 40-50 lines is pushing it. If you try to describe the function's purpose and find yourself using the word \"and\" a lot, that probably means the function does too many things and should be split into sub-functions.\n\n## Functions and Procedural Design\n**Designing a good function**\n\n A well-designed function exhibits properties such as the following:\n* Fully performs a single coherent task.\n* Does not do too large a share of the work.\n* Is not unnecessarily connected to other functions.\n* Stores data at the narrowest scope possible.\n* Helps indicate and subdivide the structure of the overall program.\n* Helps remove redundancy that would otherwise be present in the overall program.\n\n**Avoid \"chaining\" calls**\nWhere many functions call each other in a chain without ever returning to main. Make sure that main is a concise summary of your overall program.\n````\n// bad\nmain\n|\n+-- function1\n    |\n    +-- function2\n        |\n        +-- function3\n            |\n            +-- function4\n            |\n            +-- function5\n                |\n                +-- function6\n                \n// good\nmain\n|\n+-- function1\n|\n+-- function2\n|   |\n|   +-- function3\n|       |\n|       +-- function4\n|\n+-- function5\n|   |\n|   +-- function6                \n````\n\n\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjustinamiller%2Fcoding-standards","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjustinamiller%2Fcoding-standards","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjustinamiller%2Fcoding-standards/lists"}