Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Max White]

A nice little story.
If your a smart programmer, then sure, bend space and time to your will! But know that chances are you are the only one who will ever be able to work on that system, so you better be in it for the system life span, or your just giving everybody around you a headache.

While public attributes seem tempting because then we have more power in our system to do as we like, we use them sparingly, only using them when needed, because we don't want others to have so much rope they end up hanging themselves. So while you might get things done faster that way, in the end it leads to longer dev cycles.

Program defensively, not smart. 

[devek]

I agree, but it isn't always the programmers fault.

The problem is sometimes we just throw a hack out that "works", but isn't "done".

Powers that be think the hack is good enough...

I never found a way to communicate the problem, so I started holding back my hacks and just using them for personal reference.

[Starver]

It isn't always others.  My own programming style changes.  Ignoring the "quick script" things which aren't ever supposed to be permanent, I know that if I go back to something I did a couple of years ago I may well have changed style.

The following is a procedure in something I'm currently working with, in Perl, noting that it's only ever intended just for me, the "{}" indentations are definitely not kosher (but in this case the first two loops are intrinsic to the process, so the close-loops can afford to be abutted to the close-sub) and the "die" being unindented is a pre-emptive bit of debug code (easier to spot and clean out  later on).

Code: [Select]

sub Interpolate { for my $i (0..$#_) { while ($_[$i]=~m/\{(\w+)\}/) {
  my $var0 = $1;
die "\t/!\\ Interpolation could not find var [$var0]!\n" unless exists($WVARS{$var0});
  my $var1 = $WVARS{$var0};
  $_[$i]=~s/\{$var0\}/$var1/;
  print "\t(i) Interpolation: [{$var0}]=>[$var1] ==> [$_[$i]]\n" if ($ILEVEL>1);
} } } # END sub Interpolate

The following is something from two years ago (almost exactly, the archive folder I dug into is called "20090422", which gives a clue as to how my oft-used "d8" format strings are composed!).  I used it in a web back-end (again, Perl) that very few people have ever seen the code for, and was always 'my baby', only ever intended for my own use.

Code: [Select]

sub D8MonthLength { # How long is the month with the given d8?
  my ($d8) = @_;
  if ($d8=~m/^(\d{2})(\d{2})(\d{2})/) { my ($cc,$yy,$mm) = ($1,$2,$3);

    # Start with the special case, to smooth the flow of the rest.
    if (($mm == 2) && !($yy % 4) && ($yy || !($cc % 4))) { return 29 }   # Misreporting 1900... Need to check.
     # Is february &&   4th year && Not century (unless 4th)
    # i.e.:  Feb  &&  4th Year && Not 4th Century
    elsif ($mm && ($mm<13)) { # A good month
      return (00,31,28,31,30,31,30,31,31,30,31,30,31)[$mm];
    } else { webdie "Ill-defined month in D8 '$d8' passed to D8MonthLength!\n"}
  } else { webdie "Bad D8 '$d8' passed to D8MonthLength!\n" }
}
Note that I do actually use comments, for this, probably because parts of the code aren't quite so mnemonically written, but I don't use the "# END sub <whatever>" comment that I use (along with "# END foreach <something>", for major loops in their own right) after the closing brace, these days.  (Also, I know I did sort out what I'd done wrong w.r.t. the year 1900, but I'm not interested enough to rediscover the logic error involved.

You'll note that I'm not very object-orientated, most of the time, but here's something where I use OO for a specific package, in something else from a few years back:

Code: [Select]

sub ByteMatches { my ($n,@M) = @_; my @B = ();
  SET: while (@M) { my $M = shift @M; my %MD5ofFile = (); my %MD5s = ();
    foreach my $m (@$M) { open (my $FILE,$m) || die "Cannot read file '$m': $!\n";
      my $md5 = Digest::MD5->new; $md5->addfile($FILE); close($FILE);
      $MD5ofFile{$m}=$md5->b64digest; $MD5s{$MD5ofFile{$m}}++;
    } my @b = ();
    foreach my $MD5 (keys %MD5s) {
      foreach my $m (@$M) { if ($MD5ofFile{$m} eq $MD5) { push @b, $m } }
      if (int(@b) > 1) { $n-=int(@b); push @B, [splice @b] } else { @b = () } last SET if ($n<=0);
  } } return @B;
}
No comments there, and some other interesting brace-usage, but (although you do need to know some of the context the procedure is called in) it does read fairly well (IMO, YMMV), with the multi-statement lines being "monatomic".

Actually, I understand all the above far better than I expected to.

And if you aren't already entertained enough, by my various ridiculous coding styles, have a look at the following (complete!) script I wrote a long, long time ago.  After being disappointed my intention to show a changing coding style didn't reveal quite so much coding variation of time, I'm sort-of-happy to find that this one doesn't even use procedures!  Also, I can see exactly what it does but, after all these years, I've no idea for what reason I was trying to do it...

Code: (primegaps.pl) [Select]

#!/bin/perl/bin/perl -w
use strict;

my @known = ();

my $q = 1;

QUEST: while ($q < 20000000) {
  $q++;
  PRIME: foreach my $p (@known) {
    next QUEST unless ($q % $p);
    last PRIME if ($p**2 > $q);
  }
#print "$q\t";
  push @known, $q;
}


my @gaps = ();
my %gapc = ();
my $p0 = shift @known;
while (@known) {
  my $p1 = shift @known; my $dp = $p1-$p0;
print "$p1 - $p0 = $dp\n";
  push @gaps, $dp;
  $gapc{$dp}++;
  $p0 = $p1;
}

#foreach my $g (sort {$a<=>$b} keys %gapc) {
#  print "$g: $gapc{$g}\n";
#}

my @gaps2 = ();
my %gapc2 = ();
   $p0 = shift @gaps;
while (@gaps) {
  my $p1 = shift @gaps; my $dp = $p1-$p0;
print "$p1 - $p0 = $dp\n";
  push @gaps2, $dp;
  $gapc2{$dp}++;
  $p0 = $p1;
}

#foreach my $g (sort {$a<=>$b} keys %gapc2) {
#  print "$g: $gapc2{$g}\n";
#}

my @gaps3 = ();
my %gapc3 = ();
   $p0 = shift @gaps2;
while (@gaps2) {
  my $p1 = shift @gaps2; my $dp = $p1-$p0;
print "$p1 - $p0 = $dp\n";
  push @gaps3, $dp;
  $gapc3{$dp}++;
  $p0 = $p1;
}

foreach my $g (sort {$a<=>$b} keys %gapc3) {
  print "$g: $gapc3{$g}\n";
}
I do like my "next QUEST" and "last PRIME" bit, though.  I probably used "QUEST" instead of "SEARCH" because it had the same number of letters as "PRIME" and lines up nicely above it.   However inefficient some of the code is (never mind the resource usage behind it!), that bit at least is very aesthetically pleasing to me.

You can also see the remains of some of the intermediate development outputs, in that the sole comments are those deactivating lines of code that were used at various stages of the writing and not just excised once their usefulness was over.  Those are so terribly, terribly soul-baring!


And, yes, I know I've only included Perl stuff, that's because most of my other code isn't so personal (and personally revealing!) and therefore the style is affected and skewed by the need for other people to read it on a regular basis.  (Even when I don't like 'their' particular coding style.)  It may also be privileged, and finding something that means as nothing out of context as the first three examples (if not the fourth!) probably wouldn't be a good example of being readable/otherwise, either.  Not to mention that different languages demand (or at least request) different styles themselves, so may be a chalk'n'cheese situation.

[Max White]

So if anybody here makes games, I need some advice on my design choice. Lets assume I want different types of weapons, and different types of materials for those. So I can have swords, axes and spears for weapons, and bronze, iron and steel for materials. Now these are two ways to implement this. The first is with a class called 'Weapon description' that has a reference to a class called 'Weapon', and each weapon is an object. Likewise there is a class called 'Material' and Bronze is an object of the material class. So for some c# code

Code: [Select]

class WeaponDescription
{
public string Name {get; }
public WeaponDescription (string name) //Multiton pattern would be used in the real solution rather then a constructior
{
this.Name = name;
}
}

class Material
{
public string Name {get; }
public Material (string name)
{
this.Name = name;
}
}

class Weapon
{
WeaponDescription weaponDescription;
Material material;
public Weapon (WeaponDescription weaponDescription, Material material)
{
this.weaponDescription; = weaponDescription;
this.material = material;
}
string Name
{
get
{
return string.Format("{0} {1}", material.Name, weaponDescription.Name);
}
}
}*Note: Code quickly scrawled in notepad. Not sure to compile, just showing concept.

Or would it be better if each weapon and material was its own class, that extended from their respective higher classes? So I had a sword class and an iron class?

[Siquo]

Only if you need new functions. As Bronze only differs from Iron in it's properties, not its uses, I wouldn't make it a different class. You could, but I wouldn't This makes it more extensible as well, as you can "mod" in new materials more easily.

You could make a Weapon class with a separate descriptor (with properties such as name/blunt/sharp/area/weight/range), then if you need something that does something new, make a new class for that with .... INHERITANCE!
Such as a class RangedWeapon : public Weapon {};

You're doing it Right. (AFAI can see, and I'm not that good at C++).

[olemars]

Only if there is an implementation-specific difference that requires such subclassing, for instance Melee and Ranged weapons, although a generic weapon and material class probably won't hurt in any case.

You can pretty much change your mind whenever though, a Sword is still a Weapon and can be treated as such without losing any of its unique Swordiness.

FakeEdit: Ninja

[devek]

I subscribe to the school of though that you really shouldn't use a language feature that isn't necessary.

Why not describe your weapons and materials as structures? Your code might be a bit simpler.

Classes and inheritance are great, but you need to be justified when you use them. They either make your code more simple or they don't

This seems like a, duh thing to say... but there are people will try to cram every OO feature they can, until they are writing hundreds of lines of code that I can replace with two lines of normal code heh.

[olemars]

Structs are just classes with default public access in C++. Assuming it's the same in C#.

[Siquo]

Classes and inheritance are great, but you need to be justified when you use them. They either make your code more simple or they don't

They might make your code less simple, but more extensible. Often I have to re-do entire sections because I failed to adhere to strict inheritance and tried to do too much in a single class.

And since I'm extending my code continuously, adhering to the "everything is a class and preferably even multiple and almost everything inherits from everything else" has saved me a lot of time. In this case I'd even make a Descriptor abstract class that WeaponDescription and Material both inherit from.

Oh and Max, try to decide if you want to start your membernames with capitals or not, you're now doing both at the same time

[devek]

Oh C#, nvm... I should have finished waking up before posting.

And no, C++ is nothing like C#. C# was build on the corpse of Microsoft's "Java" implementation, which was a huge legal disaster. They made a few syntax changes and .net was born I used to joke that converting .net's bytecode to java bytecode would be easier than writing Mono, and time has kind of proven me right. Mono never worked, if it did it would violate patents, but it never will because all of their developers were fired 8 days ago The smart thing for developers to do was to avoid .net in the first place and just use Java, but omg marketing!

[Siquo]

Bad devek. Language wars go in the other thread.

[devek]

I'm not a fanboi and I don't take part in wars

[Siquo]

Hatebois go to hell, as well

[devek]

Hateboi? Possibly.

The whole story is that Miguel de Icaza is on my short list of people to cock punch if I ever get the chance. When something funny happens to him, like his entire Mono staff getting laid off, I reserve the right to mock his failure for at least 20 days

[olemars]

Classes and inheritance are great, but you need to be justified when you use them. They either make your code more simple or they don't

They might make your code less simple, but more extensible. Often I have to re-do entire sections because I failed to adhere to strict inheritance and tried to do too much in a single class.

And since I'm extending my code continuously, adhering to the "everything is a class and preferably even multiple and almost everything inherits from everything else" has saved me a lot of time. In this case I'd even make a Descriptor abstract class that WeaponDescription and Material both inherit from.

Oh and Max, try to decide if you want to start your membernames with capitals or not, you're now doing both at the same time

Inheritance is powerful, but it can quickly become too much of the good. Trying to debug and improve decade-old code with 6-7 levels deep inheritance chains is not fun at all. This was my day today...