Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

coding style discussion


  • Please log in to reply
45 replies to this topic

#41 Fred

Fred

    Advanced Member

  • Members
  • PipPipPip
  • 302 posts
  • LocationUK

Posted 25 March 2011 - 02:33 PM

What really bugs me is the way Resharper (standard at my current job) actually suggests replacing a proper declaration with var. I'm slowly becoming a bit less repulsed by var. It makes sense in some places, notably in ASP.NET MVC where it seems unnecessary importing a namespace just to use a type that can be inferred.

#42 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 25 March 2011 - 06:46 PM

Although that is an interesting match, I think we're going off the real problems of Netduino and the MF.

Any thread titled "coding style discussion" is never going to get anywhere near Netduino or MF :rolleyes:

And it's always going to be controversial.

Regards,
Mark

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#43 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 25 March 2011 - 07:35 PM

That's correct -- so long as it has a proper implementation of Equals() and GetHashCode(), which turns out to be a quite a bit of typing. You have to be a bit of an expert just to get .Equals() right.

Doesn't that contradict your original statement Situations where it is absolutely required (there is no way to avoid it) ?

I agree with you that in complex libraries it is undesirable to have to write the additional code but there are very few compiler writers in the world. These forums are here to discuss Netduino and MF. One of the challenges with MF is that we are looking at a minimal environment. I believe that in this case it is crucial that the programmer takes control and that means understanding what is happening with their code. To me var hides too much and as such can lead inexperienced programmers into problems.

It would be interesting to hear your/your company's

Standard disclaimer: All opinions here are mine :rolleyes:

take on this argument, as I would assume their interest is in minimizing the amount of code they need to test and maintain. i.e. why not let the compiler automatically supply these classes and their methods rather than put your programmers through all this busywork?

As I mentioned earlier, there are few people working on really complex pieces of software. Most of are writing code processing data and throwing it around from one class to another or to a database and so the boiler plate code can be generated using a good set of macros and some minor modification to the generated code. I agree there are cases where this will not fit.

I'm pretty surprised, as this would open the door to uninitialized variable bugs in C/C++.

There are compilers out there which can trap this sort of stuff when working with generic C/C++.

The desire to leave space for commenting does not strike me as particularly compelling, as there are lots of ways to format code which allow for copious commenting.

And if you see most of the code I work on there are few comments in these cases - only where it is not obvious. The code is the comment unless the algorithm/solution is tricky to understand.

There is never a perfect solution and coding styles/rules vary from one organisation to another. My own style has changed over the years through my experience and also taking elements from the companies I have worked for. I have not always agreed with the house style but my job is to write code which they accept - I like putting food on the table.

There may come a day when var and I become good friends but these days I work in a programming world which is not as complex as those I used to work in and so to me it is not necessary at this time. I spend a lot of time these days with inexperienced programmers and to me it is more important to get them to understand what is happening with their code so that they can work with .NET 1.1 through to 4.0.

Regards,
Mark

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#44 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 30 March 2011 - 12:13 PM

That's curious!
The great Eric posted a good article about compound operators, that involves structures also.
http://blogs.msdn.co...t-part-one.aspx
Just on this thread, I guess, we have discussed about the use and misuse of "ref" that the only way to alter struct "by-reference".
The article touches also this kind of aspect, and the hypothetical syntax introduced by Corey:

Point p1 = new Point(1, 2);
Point p2 = p1;
p2.X = 5;          //p2 changes, but p1 don't

ref Point p3 = p1;
p3.X = 10;         //p3 mutes p1, because is an alias (reference)
Good to know that is a limitation of C#, not CLR!
Maybe some day...
Cheers
Biggest fault of Netduino? It runs by electricity.

#45 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 20 April 2011 - 06:29 PM

The great Eric posted a good article about compound operators, that involves structures also.

Eric The Great has just published an article on 'var': Uses and misuses of implicit typing.

#46 Corey Kosak

Corey Kosak

    Advanced Member

  • Members
  • PipPipPip
  • 276 posts
  • LocationHoboken, NJ

Posted 20 April 2011 - 08:32 PM

Eric The Great has just published an article on 'var':

Great article! Thanks for mentioning it.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.