There is an MSDN article a book on the subject but since it is more than 10 pages only few have read it.
Alas the Corefx team created a short list with stuff here: https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/framework-design-guidelines-digest.md
It is much easier to read
Comments about rules I have found often not followed
“Do not postfix enums with Enum.” To be honest – I have often found it the best solution to postfix with Enum.
“Do not organise namespaces after company hierarchy.” Even though Conway’s law is a thing a system should not keep the history of a changed organisation chart.
“Carefully choose names for your types, methods, and parameters.” Naming things can be hard so take your time and discuss with your colleagues.
“Do not create mutable value types.” I totally agree. It is easier to debug imutable. Often when I track down a but I have only a (bad) call stack and the name of a public method and some source code. Then it is very important the code is easy to follow by hand.
“Do not use List<T> on public methods.” List<T> is a complex beast. But using IEnumerable<T> might have some reiteration performance impact, that is when you have to loop through the same collection twice.
“Do not throw
1
Exception
or
1
SystemException
.” I can count on the fingers on one hand the people, beside me, that bother with writing a proper exception. Visual studion makes it easy, just write ‘exception’ and then tab and you get the full template.
“Members returning arrays should return copies of an internal master array.” I is good OOP practice to not publish internal stuff. Correction, it is cruical OOP practice to not expose the innards of a class.
Other comments
“Prefer classes over interfaces.” Why? Context please.
IMO the linked article forgot to mention that public methods should not have optional parameters as they are compiled into the caller and not callee.
Avoid public as any change to them might break the API. Unfortunately Visual studio defaults new classes (and methods?) to public so I see them everywhere.
I am currently experimenting with using a virtual machine for my development. I have earlier done it through OSX/Parallels but now I am trying a Win/Win solution with Hyper-V.
Every third month, that is for how long the license is valid, I do a Hyper-V Manager->Quick create->Windows 10 dev environment.
The mandatory screen shot.
It comes with Visual studio and some dotnet preinstalled. All I have to do is start VS and tell it to update itself, and update dotnet core, and start VS installer and update with Web and Azure and whatnot I need for developing.
I have checked that all chocolatey packages I reference are “trusted package”. I cannot know if they packages remain “trusted package” at the time you are reading this. The choice is yours.
(there is a installation version where I clone the git repo to get the stuff on my drive and work from there; but here is another version)
Download Keyboad 1337.zip. Unblock. Unpack. Install. Run Keyboard 1337\l337\setup.exe (yupp. there’s a typo there) Language preferences -> Keep English(Sweden) and English(United States). The latter is Keyboard1337
If these 3 issues aren’t a problem in you case, be reluctant to use an O/RM as an O/RM brings a bunch of other problems.
Type security
When you get the Customer.Verified out of a database the code already knows it is a boolean. No explicit type casting or declaring is needed as it is done elswhere, once and for all.
Now this isn’t totally true but depends on whether LINQ or HQL (or for another O/RM) you are using. But basically it is true, because of solid Left-right copying
Data copying
Copying data from a recordset to the Entity is done by the OR/M and configured once and for all. Unlike a programmer it won’t forget to copy a field in an obscure corner in your code base.
It isn’t hard to write a data copying function for this simple case and dragging a whole OR/M into the project is a lot of dependencies for little use.
Turn around
When the scheme is changing fast, like in the beginning of a project, or when prototyping, an O/RM is of great help to change in one place and let the coding tools and compiler do the rest of the changes in the project.
Schemes tend to solidify after a while and only change in small increments so speeding up the first 3 months for having a rucksack the coming 6 years might not be the best solution.
In production we usually rely on logs to track down an error.
Even worse; in production we have more data and more logging to sift through than in development. The trees can be lost in the woods. If we are more unlucky we also have a time restraint.
To learn how to read a log file we must train. This means reading log files. And to read the we must first write to them; in a readable way.
So I write log files and read them to find my errors already in development. Training for production.
Learn to write
Too little information is bad. This is the usual case. Too much information is bad too as we cannot see the flow of the program due to uninteresting information. Writing the exact amount of information for every time is probably not doable but by training I learn and get better at it.
Readable code
If we develop the application through setting breakpoints and inspecting variables we are in a bad spot when production error happens as we seldom can do that.
All we have is a log with a stack and possibly a rough idea of the input.
If I instead learn to read the code and trace the execution path manually, already in the development phase, I am in a much better position when production hits the proverbial fan.
Startup time
Connecting the debugger takes time. Just starting the program is faster.
Use Set-StrictMode. See part1 of this blog series.
1
# .SYNOPSIS... #
This type of comment right before a method is recognised by Powershell and ends up in Get-Help. Adhering to explaining the intention for your methods is considered good practice.
Inside the method is
1 2 3 4 5 6 7 8
param(
[parameter(
Mandatory=$true,
HelpMessage='The name of the culprit.'
)]
[string]$name,
[datetime]$birthDate=(Get-Date)
)
This is what the parameters look like. One can set if a parameter is mandatory, some help text to be picked up by your favourite text editor, the [type] and default value.
1
$startTime=Get-Date-Format 't'
A variable is set to a string. Other scripting languages send strings around. Powershell sends proper objects. The Get-Date-Format converts the DateTime value to a string.
1
Write-Verbose "Start$startTime"
Built into Powershell is the possibility to call (almost) anything with a -Verbose flag. Only then is the Write-Verbose called. Like a simple logging level.
Nothing strange here at first sight. Until you exeute in a console. Then you realise this string is outputed; because it is not inputed into something else, like a variable.
Also “$($variable.Method)” is the way to call methods inside a string.
1 2 3 4
$foundPerson= GetPeople `
| where {$_.name-eq$name } `
| Sort-Object born `
| Select-Object-First 1
Powershell is said to be able to use Linq. This is technically true but the syntax is so weird that I have never used it. This code though has (almost) the same behaviour and is easy to read.
GetPeople is a method call. Backtick concatenate lines and circumvents that Powershell has automatic statement ending with a line end. | pipes object and not strings. where is an alias for Where-Object. The rest is… Linqish.
1
Write-Host "foundPerson:[$foundPerson]"
Write-Host an object like $foundPerson output the contents of the object. Not just the type as in C#. Write-Verbose “Stop:$(Get-Date-Format ‘t’)”
This string is outputed only if the method call is made with -Verbose. Plus an exmple on how to write a method call in a string.
1
return $foundPerson
Finally nothing surprising. Except that return can be left out to make the code harder to read.
New to Powershell? Let me jot down a few good-to-know things. Some you already know. Some might save you hours of googling.
Use Set-StrictMode -Version 2.0.
Powershell 5.1 is the last Windows Powershell. From 6 it runs on Dotnet core and more platforms.
Use Pester for automatic testing. It runs tests and can mock. Note that mocking works differently in Powershell than C# as they load code in different ways.
Don’t patch together your Powershell scripts. Use the systems thinking you usally do and create a sturdy, thought out, solution with bricks of the right size. Just like you would any other solution.
For caveats let me explain the file below, row by row.
File JustASimpleScript.ps1
1 2 3 4 5 6 7 8 9 10 11 12
Set-StrictMode -Version 2.0
$temp
$temp = 'LocalVariable'
function LocalFunction( $foo, $bar ){
Write-Host "Local variable is $temp."
$foo # The last executed row is returned.
}
LocalFunction 'MyParameter'
Enter the above in your favourite text editor. Save it as JustASimpleScript.ps1. Open a console and navigate to the proper folder. Execute Powershell to get Powershell started. Then execute .\JustASimpleScript.ps1′. The result shows both an exception and some more proper output.
1
Set-StrictMode -Version 2.0
Set-StrictMode is like `option explicit` in old VB6, it throws an error if you try to evaluate a variable that has not been set, that parenthesises are not used when calling functions and called methods do exist.
No code example at Stackoverflow shows it and almost no blog article.
1
$temp
Variables are recognised by the leading dollar sign.
As we used Set-StrictMode above this row throws an exception. But… the program continues to run!
1
$temp = 'LocalVariable'
Strings are delimited with apostrophes. Quotation works but is over kill, see below.
1
function LocalFunction( $foo, $bar ){
Nothing special about declaring a function like this. Declare a function with parenthesises but call it without; it is very easy to get this wrong. Also; the parameters are optional by default.
1
Write-Host "Local variable is $temp."
Write-Host is the normal way of outputting text in the console. If it is the correct way is another discussion I won’t dive into without more knowledge.
Also note the quotation marks. They mean that anything that looks like a variable inside should be evaluated. Just like PHP. Just like C# by prefixing a string with $. Many online examples use quotation marks for every string. By the time of writing I consider that less good.
1
$foo # The last executed row is returned.
To fool newbies, Powershell implicitly returns the last executed row with an output. I suggest to make it more readable, prefix with return like so:
1
return $foo # The last executed row is returned.
Comments starts with a # sign.
1
{...}
Stuff within curly brackets are a code block. A code block is not only the contents of a method or an if statement but can also be passed around, like a() => {…} lambda in C#.
1
LocalFunction 'MyParameter'
This ia a method call. As long as it is Powershell leave out the parenthesises. Otherwise you have converted your list of parameters to a single parameter call and the single parameters is a list. This rule is not hard to remember but reading code that calls method with lists as parameters is hard to grasp for a newbie. Adding insult to injury, calling a C# method from Powershell might change the rule.
Using a file like this, ending in ps1 is typically done by “dot sourcing”. It is quick, dirty and pollutes the global name space. Things you would never to in your “regular language”.
A call like below makes the contents live only just in the call.
1
.\JustASimpleScript.ps1
If you want to make the $temp variable and the LocalFunction live on you start it with yet a period and a space like so:
