Creature File Formal Style

[GriffonSpade]

Looking to get a few clarifications/judgements on the Formal Style preferred by those in charge of maintaining the code.

First, is it truly necessary for everything to be tagged with 'this.', which is rather redundant due to the Casing Rules that are adhered to, as helpfully pointed out by @Jack? See here.

Second, is it always preferable to include the braces in single line checks?
ex:

if (x)
{
	y;
}
else
{
    z;
}

Or is it fine to leave them out if all the checks have only one line like this?

if (x)
	y;
else
	z;

Third, can essentially single code-line modules be shortened into a single line to increase readability?

ex:

  public override OppositionGroup OppositionGroup
  {
  get
  {
  return OppositionGroup.FeyAndUndead;
  }
  }
  public override bool Unprovokable
  {
  get
  {
  return true;
  }
  }
  public override bool BleedImmune
  {
  get
  {
  return true;
  }
  }
  public override Poison PoisonImmune
  {
  get
  {
  return Poison.Lethal;
  }
  }
  public override int TreasureMapLevel
  {
  get
  {
  return 5;
  }
  }
  public override int GetIdleSound()
  {
  return 0x19D;
  }

  public override int GetAngerSound()
  {
  return 0x175;
  }

  public override int GetDeathSound()
  {
  return 0x108;
  }

  public override int GetAttackSound()
  {
  return 0xE2;
  }

  public override int GetHurtSound()
  {
  return 0x28B;
  }

Instead shortened to this: (Although, notably, I'd sort them)

  public override OppositionGroup OppositionGroup  {  get  {  return OppositionGroup.FeyAndUndead;  }  }
  public override bool Unprovokable  {  get  {  return true;  }  }
  public override bool BleedImmune  {  get  {  return true;  }  }
  public override Poison PoisonImmune  {  get  {  return Poison.Lethal;  }  }
  public override int TreasureMapLevel  {  get  {  return 5;  }  }

  public override int GetIdleSound()  {  return 0x19D;  }
  public override int GetAngerSound()  {  return 0x175;  }
  public override int GetDeathSound()  {  return 0x108;  }
  public override int GetAttackSound()  {  return 0xE2;  }
  public override int GetHurtSound()  {  return 0x28B;  }

Fourth, and I guess this mostly applies to non-mobiles, is it preferable to use straight boolean checks?ex:
if (!boolean)
if (boolean)

or should the value be checked?
if (boolean == false)
if (boolean == true)

Fifth, can the public : base be declared on the same line?
ex:

  public AncientLich() : base(AIType.AI_Mage, FightMode.Closest, 10, 1, 0.2, 0.4)

or should it be on separate lines?
ex:

  public AncientLich()
	: base(AIType.AI_Mage, FightMode.Closest, 10, 1, 0.2, 0.4)

Sixth, should I use tabs or spaces for indents? (please say tabs, lol)

 

[Po0ka]

I'm not maintaining but here's my thoughts on that:

1: Don't put "this." everywhere, this is a real plague. Only use it when you need a reference to the instance like sending itself to a function or such.

2: I don't like when people put braces around single lined conditions... But from what i could see, every scripts in ServUO that i compared with RunUO used braces, so that's the way to go i guess.

3: For the third i prefer one lined but ServUO seems to be multi lined.

4: Don't ever put "boolean == false", that's not a coding style, it's bad coding

5: It seems it is on another line.

6: Please, use tabs.

Most of the stuff is probably due to the default coding style of VS, someone probably didn't bother editing them all, considering changes are pushed by the users most of the times, ensuring consistency is not easy, and if everything was different it would be hard to maintain.
There are various reasons why i don't bother to code on servuo and one of them is the coding style.

 

[tass23]

Just to add one note to this, but I have noticed too that using WinMerge, sometimes braces don't get lined up properly and the more you continue to merge across that changes established braces, throws the code way out of whack and sometimes it's difficult to fix multi-level braces that aren't lined up.

My personal opinion though is: I learned scripting mainly working on my shard over the years, although I originally had some background in logic and programming. Thus, I sort of adopted established coding practices being used be RunUO, OrbUO, ForkUO, and ServUO now. From time to time, I see coding styles swing back and forth, i.e. braces all on one line, instead of split into separate ones, etc. Use what is comfortable AND decipherable by other coders, is my suggestion. From a support perspective, looking at code that is all crammed in one line that runs twice the width of my 22 inch widescreen, really sucks LOL

I think most people here are using some version of VS, and/or a program like Notepad++, and I have noticed sometimes that things don't line up from program to program. My guess is that in more than a few of those cases, people are using spaces, instead of tabs too though.

 

[GriffonSpade]

Yeah, sounds similar to my background. Highschool BASIC and Visual BASIC, plus messing around with spreadsheets. This stuff has a very smooth difficulty curve, so even with zero experience with c#, you can immediately start coding and learn as you go.
I indent based on a 4-space-wide tab, which I think is the usual. Using a different tab width setting will throw off some things. Notepad++ all the way!
I too hate ridiculously long checks, even if they're on multiple lines. They get stupid hard to read. If at all possible, it's better to break them down or invert their logic if at all possible IMO. Creature public : base lines are actually pretty modest in width, but I suppose if you're trying to work with it in half screen, putting it on one line would make it too long. On the serial, it just looks silly because it's so dang short.
Sticking all braces on one line sounds like it would get hard to read, and as for the single code-line ones, well, it seems somewhat silly to spend multiple lines just to declare a variable.

 

[zerodowned]

I'm not in charge either but...

using braces after if/else statements isn't necessary, it just makes it easier to read and easier to edit - if you need to add a second like to the statement
it's not required if you're only using one like of code after the statement

3rd: I prefer the single line, makes it infinitely easier to read

Boolean or bool default value is false

Don't ever put "boolean == false", that's not a coding style, it's bad coding

oops, guilty of doing that

5th: I often see them on separate lines, doesn't really matter how you do it, but I think separate lines makes things stand out better

I <3 Tabs
and as you can see by the picture below, you're gonna have to use a lot more space bar to get the correct spacing while writing code

 

[zerodowned]

also you could do braces like this

if( something or other ) {
dothis();
}

which I personally prefer but tend to not use
what I hate though is when the else is on the same line as the ending brace for the if

if( something or other ) {
dothis();
} else

 

[Po0ka]

I'm of those who hate the { at the end of a line lol
My mind is made to read "bracket to bracket" rather than "if to bracket" xD

 

[GriffonSpade]

I'm of those who hate the { at the end of a line lol
My mind is made to read "bracket to bracket" rather than "if to bracket" xD

Ditto, that stuff is hard to read for me. The check is the head, the brackets are part of the body. Mincing that just makes me liable to miss things.

 

[Ravenwolfe]

While there is no "official rule" on this, we have a resharper license and it is helpful to code following the standards that resharper uses (otherwise you get warnings in VS.

Basically, we will accept code any of the ways you mentioned but we love it if it uses tge following: (using your questions)

First, dont use "this" unless necessary for clarity.

Second, preferred to use braces even on single lines.

Third, single line code is preferred.

Fourth, straight boolean checks.

Fifth, doesnt matter to resharper. VS likes to seperate the lines, I usually put base on same line for readability.

Sixth, resharper doesnt care. I like tabs, much of the code is spaced. Go with what you know.

Basically, we are not formal and not picky. Go with what you are comfotable with. If you want my opinion, the only ones I care about are using "this" and the boolean. Both of those really piss off resharper, lol.

Thanks for asking, but we love to get code anyway we can. If it really bugs us, we can always tweak at merge time, lol.

 

[Ravenwolfe]

I'm of those who hate the { at the end of a line lol
My mind is made to read "bracket to bracket" rather than "if to bracket" xD

VS does that to me sometimes, i hate it!

 

[GriffonSpade]

Alright, good deal . Now I have a good idea of what I should do, and what I should fix if others do and I come across it .