Linked by Thom Holwerda on Tue 15th Jan 2013 21:24 UTC
General Development "I was really excited to write this article, because it gave me an excuse to really think about what beautiful code is. I still don't think I know, and maybe it's entirely subjective. I do think the two biggest things, for me at least, are stylistic indenting and maximum const-ness. A lot of the stylistic choices are definitely my personal preferences, and I'm sure other programmers will have different opinions. I think the choice of what style to use is up to whoever has to read and write the code, but I certainly think it's something worth thinking about. I would suggest everyone look at the Doom 3 source code because I think it exemplifies beautiful code, as a complete package: from system design down to how to tab space the characters." John Carmack himself replies in the comments.
Thread beginning with comment 549035
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Good article
by henderson101 on Wed 16th Jan 2013 16:38 UTC in reply to "RE[2]: Good article"
henderson101
Member since:
2006-05-30

Personally I like VB.NET, while the syntax is odd you can write code pretty quickly.


Oh jesus.. no it's not! Here is an example:

Define a class and on that class create a public event


Public Class Whatever
  ...
  Public Event MyEvent(ByVal SomeValue As String)
  ...
  Public Sub RunHack(ByVal whatever as String)
    MyEvent(whatever);
  End Sub
End Class

Then in another class try this:


Public Class TwatFace
  ...
  WithEvents myHack as Whatever
  ...
  ...
  Public Sub ABadIdea(ByVal whatever as String) handles myHack.MyEvent
    MsgBox(whatever)
  End Sub
  ...
  Public Sub LetsBreakEventHandling()
    Dim fcukit As New Whatever
    myHack = fcukit
    myHack.RunHack("Shoot yourself now...")
  End Sub
  ...
End Class


What happens if we call LetsBreakEventHandling? Well, it should never compile... it does. It should probably freak out and crash, but you'll see a message box happily telling you "Shoot yourself now...". And I know all of this because the fcukwit programmers, on contract from India, that we used before I took over didn't know about "AddHandler Xxxxx, AddressOf Yyyyy".

Even with option explicit and strict on, you can do this:


Dim X as Integer
X = 99
Dim Y as Boolean ''uninitialised, so compiler decides

Select Case X
  Case 1, 2
    Something()
  Case 3, 4
    Somethingelse()
  Case Y
    WhatThef--kDoesThisEvaluateTo()
End Select


VB is dangerous, plain and simple and there's nothing you can do in VB that can't be done in a safer .Net language at a similar speed.

Edited 2013-01-16 16:43 UTC

Reply Parent Score: 2

RE[4]: Good article
by lucas_maximus on Wed 16th Jan 2013 16:43 in reply to "RE[3]: Good article"
lucas_maximus Member since:
2009-08-18

Look I am sorry you have a crap codebase, but the fact remains the same ... you can write bad code in any language.

Edited 2013-01-16 16:45 UTC

Reply Parent Score: 2

RE[5]: Good article
by henderson101 on Wed 16th Jan 2013 16:48 in reply to "RE[4]: Good article"
henderson101 Member since:
2006-05-30

Look I'm sorry you like VB, but the fact remains you can do better in just about any other language that targets .Net/CLR. VB is shit and it always was. VB lets you do completely unsafe things and even when you tighten it up to require as much safety as possible, it still lets you do ridiculously stupid things. A bad programmer can write reasonable code in C#, because there is a lot of padding to protect them, not least proper type safety. A bad programmer will hack together a horrible solution in VB.

This has nothing to do with the code base. I've dealt with very competent programmers using VB, and the C# translation is still far less unsafe due to the greater type safety and lack of silent casting and type munging that VB does in the background.

Edited 2013-01-16 17:08 UTC

Reply Parent Score: 2

RE[4]: Good article
by Nelson on Wed 16th Jan 2013 17:24 in reply to "RE[3]: Good article"
Nelson Member since:
2005-11-29



Oh jesus.. no it's not! Here is an example:

Define a class and on that class create a public event


I don't think what he said is untrue, just less true for some than others. People with a strong VB background have picked up VB.NET rather quickly (to my dismay, Id rather see it die a cold death, but ah well)

I think your counter-point underlines his point quite well though, in that WithEvents is a construct included in VB.NET for pure legacy reasons.

C# has the advantage of being able to learn from the mistakes of other languages, whereas when VB.NET was being developed, they likely valued VB familiarity over purity.

That's why you can do stupid things in VB.NET, but you can also do stupid things in C++, in Java, and in C# (Look at boxing before Generics for example).

C# not having as many ways to shoot your foot off is a testament to C# as a language, sure.


VB is dangerous, plain and simple and there's nothing you can do in VB that can't be done in a safer .Net language at a similar speed.


VB.NET is completely type safe.

Also, the switch statement with a boolean is probably going to evaluate to zero, because that's what a bool of false (default value for the bool value type) evaluates to when converted to an int.

Reply Parent Score: 2

RE[5]: Good article
by henderson101 on Wed 16th Jan 2013 17:45 in reply to "RE[4]: Good article"
henderson101 Member since:
2006-05-30

With regards to "WithEvents" - yes probably. But that's not what the MSDN says. As far as I can see, it's required when the "handles" clause is being used. That's not really legacy then.

VB.NET is completely type safe.


No it's not... not in the "you can't use the wrong type because it won't compile" sense of the notion. VB will happily munge and cast between integral types and Decimal/Double. VB will silently cast a Boolean to an integer. This should not compile, but it does:

Dim X as Boolean

Function WFT as Boolean
Return X
End Function

....
Switch Case Y
Case WTF ''This could be anything
....

Also, the switch statement with a boolean is probably going to evaluate to zero,


Yeah, probably. But when you have to run code to verify that fact, it's screaming "walk away" to me.

because that's what a bool of false (default value for the bool value type) evaluates to when converted to an int.


And the compiler silently casts the Bool to an Integer. That might be how VB6 worked, but VB.Net uses the CLR and so an explicit cast is required. How helpful VB.

Oh, and rewinding to "type safe".. try turning off Option Strict and Option Explicit and see how much worse you can make stuff... you don't even need to declare the return types of Functions... VB just guesses for you and silently casts the result to the type you assign the result to. Even with it on, you can still do everything else I mention. The first thing I do with VB code these days is look at the project properties and if it isn't already set, build it with Option Explicit and Option Strict turned on and fix all the errors. It is far, far too common to still find shops using VB.Net as if it was VB6.

Reply Parent Score: 2