IIRC the most usual, unwanted, exception we get is null reference error. The second is off-by-one error.
The off-by-one error is the result of us programmers on remembering to subtract one from an index, or subtracting once too many.
Alas we should have 1 based index, like natural language, and let the computer do the subtraction.
What…? That is not how computers work!
No.
But that is how Humans work.
It is many years since we stopped arguing that a computer wants its data layed out such and therefore we adopt to it. Today we try to solve business problems, not computer problems (your domain may vary). We use higher level language. We name our variables after the domain. We use domain language.
We do not ask the customer for the zeroth invoice. And when we ask for the 2nd invoice we expect the 2nd invoice in a list.
The reason for 0 based index is, I believe, a historical technical reason.
When programming assembler, it is easy to point to a memory position and then add an index. Hence having a zero based index is a natural thing; we solve a computer problem. Then C, a higher level language, comes along. It is way above assembler but is till constructed to be close to the physical machine to be easy to implement on any processor. By that time we still solved computer problems and keeping a zero based index was probably a no brainer.
Then came Java and C#. They try to look like C/C++ due to reasons of not-thinking-things-through and it-is-easier-to-not-move-the-cheese. They keep the zero based index even though they didn’t have to. So now we are stuck with it.
Until either 1) we invent a new operator
1
myArray@1
or
1
myArray/1/
or 2) invent a yet new language.
Until then: Keep spreading the word that we should have a 1 based index.
It is a good custom to write out Act and Assert in test as it helps to write the test in a clean way; and helps the next reader to understand where Arrange stops and Act begins. It helps the writer to not involuntarily write Act statements in Assert. Like so:
myTest() sut = setup()
// Act. sut.do()
// Assert. assert(sut.value).equals(12)
The above code is too simple to make the upside of this coding standard visible but soon tests get a few lines long and commentning Act and Assert is a good idea.
I don’t bother to write out // Arrange any more as all tests start with Arrange anyway.
Well… that was not true. I have stumbled upon tests with several Arrange, Act and Assert in them. Typically for integration tests.
When figuring out how to write a test – add an assert that always fails in the bottom. Remove it when you know the test works as it should.
Why: Because you might get interrupted to spend energy on something else. When you get back the test shines red and you know where to continue. No risk of sending sub par test code to a PR.
One cannot point at a folder and just start, as we did with the full framework. There seems to be several solutions for Core and the one described here requires a publish. (Visual studio 2017:menu->Build->Publish)
Publishing a dotnet core site copies relevant parts to a folder
Until Microsoft implements change feed notifications for deletions we have to soft delete items in Cosmosdb if we use change feed notifications.
TL;DR
Cosmosdb has a handy feature where it journals changes which can then be read in another process. My use was for updating an Azure search index (Elastic search variant) whenever I made a change.
But… how do we handle deletions?
Hidden in the documentation is the information that ,,albeit all changes (within a shard) is guaranteed to be in chronological order it is always the last (present) item handed to the change feed process. So when an item is deleted there is no item and, due to implementation, also no event.
Remedy 1: Soft delete the item by marking it as “deleted”. This is a common approach in many a system. A drawback is that the repository will end up with stale data.
Remedy 2: Soft delete the item as above. Then make sure this information has been conveyed (in my case the item should be deleted from the search database) before properly deleting it. This is a more complex solution where the logic still has to handle soft deleted items while also adding the complexity of yet a process to scan(?) the repo for items to delete.
Your turn
I have found no uservoice, github or azurefeedback item for voting on getting a delete event; the closest is an item for getting a event for it in Azurefunctions. In lack of better place I voted there; so can you if you have the need.
Update
I wrote a suggestion of my own here at azurefeedback. I did try to find an existing suggestion but failed. Am I the only one deleting data? Or the guys at Microsoft will find an already existing suggestion where I can move my votes.
Comments about rules I have found but 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.
“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.
Other comments
“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 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 studio 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 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/Win by the means of Parallells but now I am trying a Win/Win solution with Hyper-V.
Every 30 days or third month, I have seen both, is for how long the license is valid, I do a Hyper-V Manager->Quick create->Windows 10 dev environment and 30 minutes later, or so, the new VM is up and running.
Microsoft packages and delivers the new download on the very day of expiry so it is not possible to download a VM a day before and prep it. It means the VM is out of date the moment you have installed the new one.
But there is a work around, open a console in admin and
1
slmgr –rearm
and you have 90(?) new days. This can only be done once per VM.
Also note that the Hyper-V manager gui, as depicted below, does not refresh its “Create virtual-machine”-content so the date of the template might be old. Restart (the host machine?) to refresh it.
The mandatory screen shot.
It comes with Visual studio, Visual studio code, Powershell 6 and some dotnet preinstalled. All I have to do is start VS and tell it to update itself..
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.
To make it even cooler one can install more stuff, like oh-my-posh. For it to work one needs a new font “Cascadia Code”, and Windows terminal has to be updated to use it.
1
"fontFace": "Cascadia Code PL"
1
Import-Module oh-my-posh
1
Set-ThemeParadox
I like to have a clear separator by every promp. So I might add a newline before the prompt
I believe Keyboard1337 is a zip if you git clone BecarroInamovible. If so, you don’t have to download Keyboard1337.
Otherwise download
1
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 Right-left copying
Right-left 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.
