OK so just to be clear?
Capital Case for Properties and Methods, camelCase for fields and camelCase for local variables? So then when you print out the code for a code review how do you tell the difference between a local variable and a field? ;D
Well, a local variable will be declared locally 
While I’m still awaiting my Domino (never had an Arduino either; complete newbie at this low level hardware stuff but with familiarity through an EE father :)) I would like to suggest underscores before member variables (fields) as this is a relatively old C++ standard. It’s not so much for readability, as it used to be in the days of C++, as it is for ensuring that member variables appear first in intellisense 
I’ve found it’s actually easiest to just leave the formatting up to Visual Studio defaults - that way everyone can complain about something instead of some people being completely happy and others being completely unhappy 
Geir, no it couldnt be, because the checksum hasn’t been read with the sentence. Some GPS devices are lazy and don’t send one, so end with a \r, \n or \r\n.
kurt, you guys print code for review??
Dashus, underscores make code harder to read, and they make it harder to find in visual studio. Sure, they might appear at the top of the list but if you have an inkling of what you’re looking for you should be just typing the field name. These are just a few of the reasons why Microsoft Best Practices do away with archaic c++ _ prefixes that come from even more archaic c days.
Mark,
Yes we print code for code reviews. It makes it easy to have teleconference if code is referred to by page and then line. Once the code is printed the underscores are the only way to know it is a member variable or if it was a class field.
From the best practices:
Do not use a prefix for member variables (, m, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.
“this.” is another way besides “_” to determine local vs class-scope and I might argue easier to spot but I’m willing to defer to the best practices on this one: I stand corrected and retract the suggestion 
Who knew I’d be a fuddy-dud when it came to programming practices just a few years out of college? :o
MarkH,
Wouldnt the natural approach be to read a complete NMEA sentence from ‘$ to the line terminator (\r \n or \r\n) and handle the string afterwards? If the split on ‘* yields only one element, then there is no checksum, else the checksum is in the second element.
Are there really GPS receivers that dont supply a checksum?
Using this. and Me. actually slows down the execution speed of the process as it takes longer to reference oneself then to reference the field. This was proven by our internal tests. The slow down isn’t significant for small apps but since we’re doing embedded development I strongly recommend against using the “this” keyword.
Unless you’re not using the compiler with Visual Studio I’m going to have to respectfully disagree with that statement: the compiler outputs absolutely [italic]identical[/italic] IL for this.field and field. I find this kind of stuff fascinating so I had to write my own test: ;D
public class MyObject
{
private bool myBool;
private bool myBool2;
private Stopwatch sw = new Stopwatch();
public MyObject()
{
long totalThis = 0L;
long totalNoThis = 0L;
for (long i = 0; i < 1000000; i++)
{
totalNoThis += TestNoThis();
}
for (long i = 0; i < 1000000; i++)
{
totalThis += TestThis();
}
Debug.WriteLine("This: {0}", totalThis);
Debug.WriteLine("No This: {0}", totalNoThis);
}
private long TestThis()
{
sw.Reset();
sw.Start();
this.myBool = !this.myBool;
this.myBool2 = !this.myBool2;
sw.Stop();
return sw.ElapsedTicks;
}
private long TestNoThis()
{
sw.Reset();
sw.Start();
myBool = !myBool;
myBool2 = !myBool2;
sw.Stop();
return sw.ElapsedTicks;
}
}
I concede that the code above is in the full .NET framework but the compiler produces the same IL for the accesses to member variables under consideration regardless of framework as it must compile into CLR-compliant code. Most importantly the order of the for loops changes which goes faster.
The following was compiled with the .Net Micro Framework 4.1
public MyObject()
{
fieldBool = true;
this.fieldBool = false;
}
It’s easier to just check the IL:
.method public hidebysig specialname rtspecialname instance void .ctor() cil managed
{
.maxstack 8
L_0000: ldarg.0
L_0001: call instance void [mscorlib]System.Object::.ctor()
L_0006: nop
L_0007: nop
L_0008: ldarg.0
L_0009: ldc.i4.1
L_000a: stfld bool ChipworkX_Application1.MyObject::fieldBool
L_000f: ldarg.0
L_0010: ldc.i4.0
L_0011: stfld bool ChipworkX_Application1.MyObject::fieldBool
L_0016: nop
L_0017: ret
}
Sorry if I seem to be contentious; not my intention, just like sharing the inner workings of .NET
Geir, the way i did it was to be as fast as possible to execute. Sure it might be more elegant to split the string after reading the whole thing in but it’ll be a whole lot slower.
MarkH,
Im sorry to hear that the built in functions in C# are so slow. You are obviously more experienced in this than me, for now the string handling looks more like C++ from Arduino then C# to me.
lol Geir.
Using regular expressions for that string processing would be nice. It’s on Microsoft’s “TODO” list as a nice to have though.
Alright, no underscores it is. I guess times have changed.
RegExp is too slow and too processor intensive for this, although it would be nice.
Personally I cant see what you would use regular expressions for when it comes to parsing an NMEA sentence? You only need to split the sentence on the delimiter ‘, and that can easily be done with an:
string[] Elements = NMEA.Split(',');
Or am I missing something?
Nope, you have it spot on. Just need a way to extract tokens from the NMEA sentence.
The method would have to be very memory efficient and then CPU efficient. Is it possible to write functions for .netmf directly in IL?
What’s “IL”?
IL is what .net gets compiled down to “intermediary language”
Does the code actually have to be lighting fast? After all the refresh rate of the GPS object is set by the speed of the GPS receiver and many of them are sending data over a slow 4800bps baud line. And lets face it, the parsing of the sentences are not complex.
Ill rather go for code that is easy to follow rather than some optimized code that shaves only micro seconds of the execution time.