Use a mindful subset of C#
Opened this issue · 2 comments
The Subset
The purpose of this issue is to define what subset of the language we want to use. This is certainly a matter of preference, but every decision is with a purpose.
high-level code should not distinguish between int
, uint
, UInt32
, etc. Where we are marshaling/demarshaling some data for a communication protocol it might be appropriate, but when we are only maintaining in memory a value in the ballpark of 0-5000
or 0-72
, it should just be an int
. Generally uint
doesn't mean an integer that's never negative, it means an integer that may numerically surpass INT_MAX, and should be considered positive in that case. Using uint
in these cases isn't wrong, per say, but it's weird and adds extra casting and an extra decision to make every time when making a new integer variable.
Avoid C# getters/setters. They break an important syntactic precept across languages. Expressions of the form a.b = c.d
do not have side-effects. These do have a place in the language, for instance to allow the execution of trivial conversions. sensor.tempC
could run a little method that converts sensor.tempF
to celsius. We should not use them to delegate device communications. I am electing to discontinue all additional C#-style dot setters in this project, and I intend to unravel existing ones that significantly intersect my development path. The previous sentence may be obsoleted soon. For now, EnlightenMobile code that uses C#-style dot setters is simply non-compliant with issue #33.
Thirdly, and finally for now, we shall avoid XAML for XF UI. Xamarin Forms is historically buggy and a lot of the bugs/limitations have to do with incorrectly parsing XAML or not supporting things via XAML. Workarounds are often applied in C#, making it no longer convenient to use XAML in the first place.
Pure-UI
Pure-UI refers to actions that could be done via XAML. These include adding controls, setting width and height, setting callbacks. Alternatively, the body of a callback might be UI code, but it's not Pure-UI. The point of this concept is that this is the kind of code we want to avoid straddling over both XAML and C#. It should be one or the other.
We want to avoid code like (pseudo)
# .xaml
<Button x:name=laser-on></Button>
# .cs
get("laser-on").title = "Laser On"
get("laser-on").onclick = enable_laser_fn
Obviously it's problematic when trying to set something in xaml and it gets shadowed by a C# program. In that case we may rather handle it completely in xaml:
# .xaml
<Button x:name=laser-on title="Laser On" onclick=enable_laser_fn></Button>
or (better) completely in C#
var laserBtn = ...
laserBtn.title = "Laser On"
laserBtn.onclick = enable_laser_fn
get("main-page").addChild(laserBtn)
I am electing to discontinue all additional C#-style dot setters in this project, and I intend to unravel existing ones that significantly intersect my development path.
Note that all of Wasatch.NET is implemented this way, and it will need to stay that way for the foreseeable future. Many customers are already accustomed to its API.
Note that all of Wasatch.NET is implemented this way...
This style guide is exclusive to EnlightenMobile.