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 549050
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Good article
by Nelson on Wed 16th Jan 2013 18:24 UTC in reply to "RE[5]: Good article"
Member since:

I agree with you that VB is terrible, but it doesn't make it type-unsafe because of it.

I think casting is more of a gray area and VB.NET definitely has more ambiguity. Its harder to know at a glance if something is correct.

C# does some implicit casting too, if you define an implicit operator overload. I'm sure VB.NET does something similar to manage to stay within the CLR sandbox.

What VB.NET does imho, is wrap bad ideas around syntax. Examples being like you said implicit conversions (which imo have always been a bad idea no matter the language) and implicit late binding.

VB.NET takes late binding, implicit typing, and implicit casts and muddies the waters into this incomprehensible soup of syntax.

However, it is still easy for VB developers to pick up VB.NET . That's always been the reason imo for VB.NET's existence. I'd never write any meaningful amount of code using it.

I think any time someone uses dynamic in C#, late binding in VB.NET or find yourself using some of these more weird features, they need to step back and think about what the hell they're doing.

Reply Parent Score: 2

RE[7]: Good article
by lucas_maximus on Wed 16th Jan 2013 19:24 in reply to "RE[6]: Good article"
lucas_maximus Member since:

I agree that VB syntax isn't the best.

I have mostly written C#, Java, PHP and JavaScript. I have never coded in classic VB, So I tend to write VB like C#.

We have a lot of points in our code base (that is mostly inherited), where Try ... Catch is mis-used, and that is one of the better things I have to deal with.

* Functions doing more than one thing and multiple return values of the same type (usually string) which mean different things depending on how it is used.

* Very misleading variable names.

* Try ... Catch misused.

* Lack of understanding for some key OOP principles, a classic being two different types having say the first 5 properties and methods being exactly the same and having 2 or 3 properties that are different ... it is screaming to use inheritance, but it was just muddled together.

I could go on, but my main point was that any one of these problems aren't down to the language but down to lack of understanding of principles. I don't think any language magically fixes those.

Reply Parent Score: 2

RE[8]: Good article
by henderson101 on Fri 18th Jan 2013 13:59 in reply to "RE[7]: Good article"
henderson101 Member since:

I've been working with a contractor (politically, I had nothing to do with him being hired for the project - I would have vetted him better, but he's actually being subcontracted to a third party who seem happy not to care.) He doesn't believe in inheritance. It drives me absolutely insane. He will do exactly as you say. He's very pattern orientated, but prefers using interfaces and single level hierarchies. I came from a Delphi background and I'm used to using interfaces to create a contract that is implemented in a class, but also creating hierarchies that build up reusable blocks of code. The flat namespace approach really doesn't make sense to me at all. Example: I have a requirement to implement a set of classes to process allocation of a table based set of prices, which differ by application. I personally would create a base class with the commonality in it, then build classes on top of that to implement the specifics. I would more than likely create an interface with the specific details for accessing any of the children generically, I'd utilise abstract and virtual methods/properties to ensure the interface could be applied at a level where it made sense. He on the other hand would create one interface and implement a new class for each different use. His argument is that inheritance causes complexity that can be avoided, but I've worked on some stupidly complex class hierarchies that were poorly designed and still simpler and easier to maintain that a class per implementation of the functionality with lots of boiler plate code included.

Edited 2013-01-18 14:04 UTC

Reply Parent Score: 2