Yegolev Learns C# - was Your app's data

[MahrinSkel]

Mine was upper-case vs. lower-case for the first letter of the name.  But I learned Pascal first rather than C (the same guy developed Delphi for Borland before he went to MS and built C#).

--Dave

[Bokonon]

I strongly suggest you develop a notation to distinguish between instance variables and local variables/parameters.

The one I use is underscore.

I disagree. If it is possibly confusing, I usually just tack on "this.", or name the parameter something to distinguish it. Most IDEs have ways for you to distinguish between them anyway.

[sidereal]

Yeah, with modern IDEs it's easy enough to trace back where your variables are declared, but I still use the Hungarian m (without an underscore) for class members out of habit.

[Bokonon]

Yeah, with modern IDEs it's easy enough to trace back where your variables are declared, but I still use the Hungarian m (without an underscore) for class members out of habit.

Yeah, habits die hard :) I mean, it doesn't hurt to do it, but it's unnecessary these days.

[Margalis]

If you are working on code that other people are going to have to interact with or that you yourself might put down and come back to down the road it's well worth it.

[Yegolev]

I am already a tad confused by C# using both camel and pascal notation, so I will either use _ or this. as a prefix.  I think I'd rather use this. for the proper separation in my mind of what language I am writing.  I suppose it is as simple as using Class this.object = new Class; inside any methods where I would be using a local?

[Bokonon]

If you are working on code that other people are going to have to interact with or that you yourself might put down and come back to down the road it's well worth it.

That's what meaningful naming is for. I only get annoyed (or simply mentally ignore) any 'm's or '_'s I see. If I am confused, I can use the IDE to find out where this variable is being defined.

Generally if I'm confused by someone's code, it's because it's confusing in general. Keeping track of member vars is the least of my problems.

[Bokonon]

I am already a tad confused by C# using both camel and pascal notation, so I will either use _ or this. as a prefix.  I think I'd rather use this. for the proper separation in my mind of what language I am writing.  I suppose it is as simple as using Class this.object = new Class; inside any methods where I would be using a local?

For locals, you DON'T use "this.". For member vars/fields/properties/variables-defined-as-class-variables-outside-of-a-method you would (or use m or _, or whatever you want).

Example (in Java, but similar to C# as I understand):


public class BokFoo
{
   private String foo; // Member variable

   public BokFoo(final String foo)
   {
      this.foo = foo; // Assigns parameter to class field
   }

   public void kungFoo(final String bar)
   {
      String foo; // local variable definition masks class field of the same name
      foo = bar;
   }

   public void noFooForU(final String foo)
   {
       String foo; // Will cause compilation error, and any decent IDE will highlight this as an error when you type it
   }
}

[Tarami]

"this" is the keyword to refer to the current instance of the class from inside the class, not the actual scope (so you can't access a static method with this.MyStaticMethod(stuff), because it's not an instanced member.)

Scope cascades in some OO languages so naming variables the same thing on several scope levels will hide the outer variable. This is not the case in C# however, it will simply generate a compiler error if you try to hide outer variables (or anything really.) This is done for clarity. You can't have a class member named "banana" and a method argument called the same (because that argument will exist in the method scope, as a local variable.) The names need to be unique all the way up to and in the class scope.

The only exception in C# is hiding of inherited members using new, but that's sorta outside the scope of this post.

Get it?

[Yegolev]

What I got was:
1. Use descriptive names.
2. Let the IDE tell you when you fuck up.

[Tarami]

...sorrie 'bout dat.

[Bokonon]

What I got was:
1. Use descriptive names.
2. Let the IDE tell you when you fuck up.

Well, I would say, let the IDE try and help as a last resort. Using descriptive names, or even prefixing properties/fields with a special character are much preferred than letting someone else's code (the IDE) figure it out for you :) Sometimes even the IDEs screw up.

[Margalis]

What I got was:
1. Use descriptive names.
2. Let the IDE tell you when you fuck up.

Develop good habits.

What happens when you starting programming in a scripting language that doesn't have an IDE beyond a basic text editor? So much for right clicking "go to declaration."

The problem with using "this" is that you don't have to, you can have a parameter named one thing and an instance variable named the same thing. You can use "this" to differentiate but if you leave off the "this" it will still work. If you name your member variable with an underscore you cannot accidentally use a local variable or parameter of the same name. Plus typing "this" every time is a pain in the ass.

If you name your member variables in a special way it makes your code easier to understand and also prevents subtle variable-hiding errors.

I prefer underscore to 'm' because it sorts better and reads easier.

[MahrinSkel]

Whereas I like the upper/lower trick because it sorts them in together and lets me get straight to the head-slapping moment as I discover yet another scoping error.

--Dave

[Bokonon]

What I got was:
1. Use descriptive names.
2. Let the IDE tell you when you fuck up.

Develop good habits.

What happens when you starting programming in a scripting language that doesn't have an IDE beyond a basic text editor? So much for right clicking "go to declaration."

Then your usage of meaningful names (as opposed to arbitrary names) will help you out.

[Yegolev]

What happens when you starting programming in a scripting language that doesn't have an IDE beyond a basic text editor? So much for right clicking "go to declaration."

I am approaching this from the opposite direction, actually.  All of the non-C# code I write (and have written for 10 years) is done in Vim via PuTTY.  If I want to find a declaration, I /varname=<ENTER> and BOOM.  For me, descriptive names are a non-issue and I am steeped in all-lower-case var names.  The only special convention I use for names is that I actually use all caps for perl filehandles, otherwise it's a free-for-all.  I am partial to one- and two-letter var names in many cases and I have code samples that would make a real (non-perl) programmer cry.  Although I am getting better since I would otherwise spend way too much time deciphering old code.  Changing a var name from $qn to $qname, for example.

I also never remember that the IDE can show me shit because I'm used to vi/Vim, so it's really a distant and bonus second after "descriptive names" since my standards are so low.  In this case, "descriptive names" includes using a convention that makes things obvious, whether it's _ or m or whatever.  I'm very about this, but I'd still like to learn the right way to do things.  Something being hard to type isn't on my list of concerns.  From my perspective, everything in C# is a pain in the ass to type, so "this." isn't even a noticeable bump to me.  My problem is actually that I don't get the scoping rules (these will come as time passes).

That said, I am interested in learning good habits... but which ones?

...sorrie 'bout dat.

I don't know what you are sorry about, unless I missed the point entirely.  Don't forget that this is just a fun thing to do, so let's all be cheerful.  Also, keep pounding things into my head until I get them, sometimes that's what it takes.

[Tarami]

Maybe I digressed a bit, that's what I meant.

Personally I think keeping variables short and concise is more important that being descriptive. Properties, yes, methods, yes, arguments, to a point, but your run-of-the-mill locals? Not really. Why bother? Having type in the variable name is to me a decent waste of succinctness (because with str, int, obj etc. as prefixes, you need to know what type it is to find it in the auto-completer, which is actually the direct opposite of what you're trying to do.) Here's a short example of my notation:

Code:

        private AggregateCache _aggregate(IEnumerable<string> files) {
            StringBuilder sb = new StringBuilder();

            foreach (var f in files) {
                try {
                    StreamReader sr = new StreamReader(Path.Combine(_physicalPath, f));
                    sb.AppendFormat("\r\n\r\n{0}", sr.ReadToEnd());
                    sr.Close();
                } catch { /* suppress and ignore */ }
            }

            return new AggregateCache(sb.ToString());
        }

Underscore for class privates (including methods), then very condensed local names.

Point being, if you have so many locals that a very short name isn't enough to make them distinct, you're probably doing something wrong. Refactor the method, split it into smaller calls that that are easier to maintain and easier to code in the first place. If you can't fit a method on a full screen height, it's time to slow down and think about what you're trying to do.

P.S. edit:
I used to use longer variable names, but recent years I've used as short names as possible. Going back to older code, I've found it's equally difficult to decipher a more descriptive name "KeyBytes" and a shorthand like "kb" because you have still have to figure out what "KeyBytes" means in this context, not just what it contains. You will never get to the point where you can look at a variable and say "this is what it stores and how what's stored in it will be used." And let's not get into variable names that are just plain misleading because you couldn't come up with a name that aptly described the data. If "KeyBytes" is storing character-encoded binary data (like "0xf5e403") rather than an array of bytes, you've already added confusion. Then maybe KeyBytesString...

So go perl'er! 

[Bokonon]

What happens when you starting programming in a scripting language that doesn't have an IDE beyond a basic text editor? So much for right clicking "go to declaration."

I am approaching this from the opposite direction, actually.  All of the non-C# code I write (and have written for 10 years) is done in Vim via PuTTY.  If I want to find a declaration, I /varname=<ENTER> and BOOM.  For me, descriptive names are a non-issue and I am steeped in all-lower-case var names.  The only special convention I use for names is that I actually use all caps for perl filehandles, otherwise it's a free-for-all.  I am partial to one- and two-letter var names in many cases and I have code samples that would make a real (non-perl) programmer cry.  Although I am getting better since I would otherwise spend way too much time deciphering old code.  Changing a var name from $qn to $qname, for example.

I also never remember that the IDE can show me shit because I'm used to vi/Vim, so it's really a distant and bonus second after "descriptive names" since my standards are so low.  In this case, "descriptive names" includes using a convention that makes things obvious, whether it's _ or m or whatever.  I'm very about this, but I'd still like to learn the right way to do things.  Something being hard to type isn't on my list of concerns.  From my perspective, everything in C# is a pain in the ass to type, so "this." isn't even a noticeable bump to me.  My problem is actually that I don't get the scoping rules (these will come as time passes).

That said, I am interested in learning good habits... but which ones?

...sorrie 'bout dat.

I don't know what you are sorry about, unless I missed the point entirely.  Don't forget that this is just a fun thing to do, so let's all be cheerful.  Also, keep pounding things into my head until I get them, sometimes that's what it takes.

When using a nice IDE (when available) don't forget that most have auto-complete, so longer descriptive names aren't any slower to type (in eclipse, the shortcut is ctrl-space to bring up a list of potential matches.

[sidereal]

There are few arguments that will cause more slapfights among developers than arbitrary coding conventions.  Avoid at all costs.  Try out a few different things and adopt the practices of other peoples' code that you find readable.  Otherwise, keep your head down and for the love of all things holy don't bring up tab or newline conventions.

[Bokonon]

There are few arguments that will cause more slapfights among developers than arbitrary coding conventions.  Avoid at all costs.  Try out a few different things and adopt the practices of other peoples' code that you find readable.  Otherwise, keep your head down and for the love of all things holy don't bring up tab or newline conventions.

Braces on their own lines 4EVAR!

;)

[Tarami]

There are few arguments that will cause more slapfights among developers than arbitrary coding conventions.  Avoid at all costs.  Try out a few different things and adopt the practices of other peoples' code that you find readable.  Otherwise, keep your head down and for the love of all things holy don't bring up tab or newline conventions.

John McCarthy has something to tell you.

[MahrinSkel]

Yeah, having learned Pascal first and being prone to longer names (multiple words with in-stream capitalization), I drive Perl and C programmers insane, who apparently are trying to use as few keystroke as possible and/or make their code incomprehensible (Perl programmers compete to create the shortest possible programs, C programmers the most impossible to comprehend).  By normal convention, the only short var names in Pascal are counters and token holders (i,j,k, x,y,z, foo, bar) that will never be used outside a single block of code.

And even then you can get into slap-fights over prefixes for objects.  For example, I prefix all of my GUI elements with a type identifier (lbl, ed, scrl, cmb, and so on), which annoys some because if you change the type, either you chase down all the references (which is kind of the point, it makes you check to be sure all your code can handle the change) or you have them mislabeled.

And there are constant campaigns to enforce common standards inside a shop for clarity, and passive-aggressive resistance to those campaigns.

--Dave

[Tarami]

C has pre-processor macros. It's basically asking you to write an incomprehesible mess. 

[Yegolev]

Braces on their own lines 4EVAR!

Oh, I laughed out loud there.  Well played.

[Yegolev]

Since we are well-derailed, and waiting for me to write more C# anyway, I will show everyone why Perl and I are going to be married one day.

Code:

for $i (reverse 0..$#su){
   push @DB,("checking line $i: $su[$i]\n");
   ($j,$md,$hm,$pm,$tty,$ft)=split " ",$su[$i];
   ($fmo,$fd)=split /\//,$md;
   unless ($nd==$fd){
      push @DB,("nowday not fileday: fileday $fd\n");
      &done;
   }
   ($fh,$fmi)=split /:/,$hm;
   ($fu,$tu)=split /-/,$ft;
   unless ($nd==$fd){
      push @DB,("nowday not fileday: nowday $nd , fileday $fd\n");
      &done;
   }
   unless ($nh==$fh){
      push @DB,("nowhour not filehour: nowhour $nh , filehour $fh\n");
      unless ($nh-1==$fh){
         push @DB,("nowhour minus one not filehour: nowhour $nh , filehour $fh\n");
         &done;
      }
   }
   if ($tu eq $u){
      unless ($ul=~/$fu/){
         ($j,$ge)=split /=/,`lsuser -a gecos $fu`;
         unless ($ge){$ge="user-id $fu no longer exists";}
         chomp $ge if $ge;
         if ($pm eq "+"){$sf="was able";}else{$sf="failed";}
         push @LA,("$fu \"$ge\" $sf to su to $u at $fh:$fmi on $fmo/$fd\n");
         push @DB,("$fu \"$ge\" $sf to su to $u at $fh:$fmi on $fmo/$fd\n");
      }
   }
}

The @DB array is a debug array.  There was a time when I would not have bothered to include such a modern innovation, since it takes up SO MUCH ROOM.

[sidereal]

Code:

...
   unless ($nd==$fd){
      push @DB,("nowday not fileday: nowday $nd , fileday $fd\n");
      &done;
   }
...

The 2nd one of those is redundant, since $nd == $fd was already checked and couldn't change in the interim.  NEXT CODE REVIEW!!!


Perl is garbage.  It's unmaintainable in exchange for requiring 30% fewer keystrokes.  That's not a good exchange.  At all.

[Murgos]

A fellow cubicle dweller once referred to Perl as a Write Only Language.

The man was a complete waste of space, but on that one point he was 100% correct.

[Yegolev]

Perl is garbage.  It's unmaintainable in exchange for requiring 30% fewer keystrokes.  That's not a good exchange.  At all.

It is if you don't maintain anything.  I say that with full awareness of what happens when you have to change something, but my job is not to write programs.  What we do around here is get The Enterprise functional and move on to the next problem, which is pretty much what Perl was made for.  It's just to make shit work and fast, and that is what I love about it, but of course people use it for lots of things today.

I'm purposely trying very hard to not bring over any of my crap procedures into C#, and even what seemingly-little progress I have made just within this thread's arc has caused some fascinating changes in how I write shit in day-to-day application.  It also helps that lately I have been re-writing a lot of code as new ideas/problems come in and the limits of my current crop of programs are glaring to me.

As for the redundancy, that's because I had originally written a long boolean that failed in mysterious ways.  This is just a quick redo in if contructs.  Since it actually works, I haven't bothered to clean it up.  I'd like to not do such things in C#.

[Salamok]

For example, I prefix all of my GUI elements with a type identifier (lbl, ed, scrl, cmb, and so on), which annoys some because if you change the type, either you chase down all the references (which is kind of the point, it makes you check to be sure all your code can handle the change) or you have them mislabeled.

This seemed to be strongly encouraged by visual studio when i was tinkering with it and made sense to me at the time.  After playing in php I have discovered the joys of storing all my form(GUI) elements in a single associative array and using the exact same names as my table fields.

[naum]

A fellow cubicle dweller once referred to Perl as a Write Only Language.

The man was a complete waste of space, but on that one point he was 100% correct.

As somebody who was paid professionally to write and maintain Perl code, that is not necessarily true, although often, people muddling with Perl (which frequently are those not firmly grounded in algorithms and good coding practices anyway) cobble up some hideous, dreadful looking code…

That being said, with Ruby (and gem(s)), there is real no reason for Perl as Ruby has all that Perl has, plus a simple, clean OO model (I WILL NEVER EVER HAVE TO BLESS A REFERENT EVER AGAIN!), much more elegant block passing (the coroutine/yield and functional programming although it's not even Lisp-ish as Javascript) and now a kick-ass web development platform (Rails for the full stack, or Sinatra/Ramaze for drop dead simple web applications along with Rack/Phusion Passenger, gives you all that PHP offers in much more elegant, joyous to write and read, bundle)… …though Ruby creator wishes to eradicate the Perlisms from Ruby (the $1, $_, $:, one liner options, etc.…), there's so much code that uses them, I doubt they ever go away totally, other than "let's try not to use these dirty Perl vestiges…"…

Or you can go Ruby on the desktop w/Shoes, or FxRuby, or recently I saw a demo with a local outfit that's selling a desktop time tracking application (JotBot), written in JRuby and totally cross-platform (they also released a Ruby gem called MonkeyBars that aids in the UI code minimizing…).

[Margalis]

Perl is great for text processing. Using it for anything else is a little silly though. I mean I would never use it for a CGI script or something like that these days but if you want to take a text file and spit out a different text file Perl is pretty damn awesome.

As far as being read-only, I took a set of Perl scripts that was made for documenting JavaScript and changed it into one that documented an entirely different scripting language in about 3 hours.

The difficult thing about Perl is that if you don't know it well it's essentially impossible to make heads or tails of it.

[MahrinSkel]

Possibly the most famous 6 lines of Perl ever:

Code:

s''$/=\2048;while(<>){G=29;R=142;if((@a=unqT="C*",_)[20]&48){D=89;_=unqb24,qT,@
b=map{ord qB8,unqb8,qT,_^$a[--D]}@INC;s/...$/1$&/;Q=unqV,qb25,_;H=73;O=$b[4]<<9
|256|$b[3];Q=Q>>8^(P=(E=255)&(Q>>12^Q>>4^Q/8^Q))<<17,O=O>>8^(E&(F=(S=O>>14&7^O)
^S*8^S<<6))<<9,_=(map{U=_%16orE^=R^=110&(S=(unqT,"\xb\ntd\xbz\x14d")[_/16%8]);E
^=(72,@z=(64,72,G^=12*(U-2?0:S&17)),H^=_%64?12:0,@z)[_%8]}(16..271))[_]^((D>>=8
)+=P+(~F&E))for@a[128..$#a]}print+qT,@a}';s/[D-HO-U_]/\$$&/g;s/q/pack+/g;eval

Any language that can produce a felony in 6 lines, I don't want to mess with.

--Dave

PS: And if Schild is feeling paranoid enough that the MPAA may still be pursuing DeCSS distribution, I'd like to let you know I've got a friend that might start posting from my house, by the name screen name of Gurghe Dumat (since I just committed said felony, and he's aiding and abetting if he doesn't take it down and ban me)

[schild]

I said What?

DeCSS has been on t-shirts for years. I think we're way past people trying to procsecute for DeCSS distribution.

[Logik]

A fellow cubicle dweller once referred to Perl as a Write Only Language.

The man was a complete waste of space, but on that one point he was 100% correct.

I've always used the WORN acronym: Write Once, Read Never.

Having said that, I echo the sentiments of Margalis.  I'm all about using Perl when it comes to text processing, but for everything else my choice is usually Python.

[Murgos]

We use a lot of Perl for processing log files and setting up clean sandboxes and environments and such for development.

No one has ever suggested using it for the actual work we get paid for though.