Language features you should never use?

Question

A recent post about the 'with' statement in Delphi - which in practice I never use because it trades clarity and ease of debugging for superficially 'cleaner' looking code got me thinking; what other language features, in any language, do you think should never be touched? - or at least avoided where at all possible?

The classic example of this would be the COBOL ALTER statement, which dynamically rewrites the executing code to change the destination of a GOTO. Use of ALTER was just about a sackable offense in every COBOL shop I ever worked in.

My supposition would be that as language design is better understood nowadays there may be fewer of these 'features' coming through - but is that true of the newer more exotic paradigms such as the functional programming languages?

Answer 1

The only thing that comes to mind are GOTO statements :)

Answer 2

You should always use Option Explicit in Visual Basic (i.e.: you should never use implicit variables).

Answer 3

I think no language feature should never be used. It's just a matter of knowing when and how to apply each feature. Of course there are features you almost never would want to use, but can still have their place in certain contexts.

Well, as every rule has to have at least one exception, here's one, PHP related:

• Having register_globals set to on should never happen :-)

Answer 4

In Java, calling a static method via a reference. My favourite example:

Thread t = new Thread(someRunnable);
t.start();
t.sleep(1000); // This doesn't do what it looks like...

It makes the current thread sleep, not the newly created one. Thread.sleep is a static method and only ever affects the calling thread - but this snippet makes it look likes it's telling a different thread to sleep.

Answer 5

In C#, extern aliases. These allow you to cope with the situation where you have two different assemblies both containing a type with the same name, including namespace, and you want to refer to a particular one of them. Avoid wherever possible.

EDIT: Just to be clear, this isn't a fault in the language. The feature allows you to get out of otherwise intractable situations. It's just a feature you don't want to have to use.

Answer 6

I agree with Vinko Vrsalovic. And my exception is the Delphi With statement. The only time I used it was to create a test set for the delphi frontend of my metrics tool.

The with statement has a very big "I want to shoot myself in the foot" factor. Which is fine if you are the only developer, but in a team it can be very nasty.

Maybe there should be a compiler option that gives warnings if with statements are encountered ;-).

Answer 7

You should never do using namespace std; in a header file in global scope in C++.

And you should be shocked if you see using namespace std; in global scope. Never do it, it throws away the names scope separation gained using namespaces.

Answer 8

Multiple Inheritance in C++, of course. There's a good reason it's been dropped in C#/java.

(Though "every rule does has exceptions, including this one").

Answer 9

In C#, you should (almost) never use [assembly: ComVisible(true)] in your AssemblyInfo.cs. It is far too easy to generate wads of COM coclasses and interfaces you're not even aware of. After all, FxCop itself considers it bad practice and recommends specyfing the [ComVisible] attribute on specific classes and interfaces explicitly.

Answer 10

You should never write Perl code without:

use warnings;
use strict;

Also, you should never use a JAPH in production code. Those are strictly for use in .signature files and golf. Their misuse elsewhere is, IMHO, one of the main reasons for Perl's reputation as a "write-only" language.

Answer 11

Global Variables.

Answer 12

It's not a language feature, but a compiler option that you should never use.

javac -nowarn myApp.java

Answer 13

I cannot find a good use for the Shadows keyword in VB .NET.

Shadows is the same as declaring a method with no modifiers, which VB's compiler doesn't otherwise allow. It creates a new name, effectively blocking all all of the overloads with that name in the inheritance hierarchy. I don't think there is a C# equivalent - for example, C#'s new is not equivalent, as it targets the hidebysig IL construct, like VB's Overloads.

If you only have one overload when you use Shadows, the behaviour matches Overloads. But maintenance developers will find out that new overloads are also hidden!

What makes this worse is that Shadows is the default. I think this may be because of VB's way of resolving an overloaded method. Unlike C#, the VB compiler does a depth-first analysis of the entire inheritance chain. Having Shadows as the default prevents base type changes modifying the behaviour of your existing code. I suppose this is a necessary evil in a world where you may not be able to control base type behaviour.

Answer 14

In C# there are a number of caveats, e.g.

Never lock on a value type - the lock keyword prevents you from doing this, but if you call Monitor.Enter() directly, you'll be locking on a boxed instance of the value. Fortunately when you try to call Monitor.Exit() on a boxed value, you'll get an exception.

Never lock on a literal string. In C# literal strings are interned for the entire application. Thus local strings, strings in different AppDomains etc. are all shared. This could lead to weird deadlock issues.

Be very careful with finalizers and try to avoid them if possible. One problem: an unhandled exception in a finalizer will take down the entire process.

Answer 15

Never use the C / C++ language feature of chaining code in a switch statement by appending code to a previous switch case:

OK -

switch (x) {
  case 1:
  case 2:
  case 3:
    ...
    break;
  case 4:
    ...
    break;

  }

Evil -

switch (x) {
  case 1:
  case 2:
  case 3:
    ...
  case 4:
    ...  // Add to the 1,2,3 case here
    break;

  }

It's too easy for someone to edit the behaviour of case 4 without noticing that it'll also affect cases 1-3.

Answer 16

C interprets nonzero values to signify true and zero values to signify false. You shouldn't have to rely on this feature any more.

Edit: Number of people are not buying my disliking nonzero-as-true. What about this?

if (status = UNDER_ATTACK) {
    launch_nuclear_missiles();
}

or this?

if(x & 2 == 1)
{
    launch_nuclear_missiles();
}

Answer 17

In C:

• Taking advantage of the commutative property of array indexing to swap the array name and the index:

  int array[5];
  3[array] = 0;
  

• Using the preprocessor to try to turn C into another language:

  #define IF if (
  #define BEGIN {
  

• The register keyword, which at best is likely to be ignored, at worst it will make performance worse, and in either case you lose the ability to take the address of your variable.

• The auto keyword, simply no need to use this.

• More of a library issue than a language feature but the gets() function should never be used.

Answer 18

I find Python's backtick repr quite nasty (and especially since there are better ways to do it.)

`some_var` == repr(some_var)     # yikes Batman (gone in 3.0 - thanks Greg)

And then there is this implicit string concatenation thing:

>>> 'a''b''c'     # holy moly Robin
'abc'

Answer 19

C++: protected inheritance

Answer 20

In PHP, never use exec or even passthru. Of course, most languages have some sort of contemporary to these functions.

Answer 21

Another PHP one: magic quotes. It's a terrible idea, and you still see lots of web apps that use it. Any time you type " and it turns into \", someone's probably got magic quotes turned on.

Answer 22

I won't say you should never use it (I am not dogmatic) but I try hard not to use automatic conversion of some values to booleans (NULL as false in C, nil as false in Lua, undefined or null as false in JavaScript, etc.).
Ie. I prefer to do an explicit comparison against the value and reserve tests like if (foo) to pure booleans.
It results in slightly more verbose code, but might avoid surprises...

In the same spirit, even though I would indulge in an occasional while (*p++ = *q++), which is at least a well known pattern, I would avoid constructs like if (a = b) even if it has the intended behavior...

Answer 23

Never omit curly braces when the target statement is on the next line

OK:

if(foo) potato

OK:

if(foo) {
  potato
}

NEVER:

if(foo)
  potato

when there's other stuff going on, it's too easy to miss that potato depends on foo.

Answer 24

I don't think there's many cases of when something should truly never be used, especially something so benign as a "with" statement (especially if it relies on non-idempotent expressions with side-effects).

Most of the issues mentioned amount to taste in formatting and syntactic sugar.

The exception may be if a feature is deprecated and replaced with an equivalent due to e.g. security issues. Even then, if you're dealing with an existing code base, it may not be worth it to go back and change to use the new features.

Some low level features that seem like security problems may be needed to communicate with other components of the system in rare cases (e.g., exec, ActiveX controls, inline assembly, p-invoke, etc). If your application doesn't need to do this, then obviously, don't use it, but it's there for those who do, and they should use it carefully. But saying "never" is way too general.

Answer 25

with in Javascript. It's a scope obfuscator/polluter and performance killer.

Answer 26

I can think of very few reasons to use exception specifications in C++:

void func() throw()
{

}

(but of course, there really are no nevers)

Answer 27

Bitfields in C. They're not portable, and they can cause concurrency problems (race conditions) when shared between threads.

Answer 28

Variable argument lists (...) unless you are writing some low level system API. In most cases, there is some cohesive intent for these lists so they're better served with a class that can take a range of things and grow its own list if necessary.

Answer 29

Variable variables in PHP.

$foo = 'Hello World!';
$bar = 'foo';

// prints Hello World
echo $$bar;

Makes debugging complicated, especially when they are combined with calling functions by name.

function hello()
{
    return "Hello World!";
}

$foo = 'hello';
$bar = 'foo';

// prints 'Hello World' too
echo $$bar();

Answer 30

Never rely on the compiler to initialize a variable. For example, never assume that integers are initialized to 0 or pointers to null. It may work fine in the current compiler you are using but could work differently when you port your code to another compiler. And, when initialization doesn't work as you expect, it will likely create a subtle and difficult to detect bug.

Answer 31

Personally in Java I do not like do while loops, I seem to be able to use While and For loops just fine, but I wouldn't say you should NEVER use them.

Answer 32

All I can add is: try to avoid platform specific APIs (Windows programmers generally don't think much about it, rather Windows is meant for this purpose). Portability is one thing you should keep in mind (as far as you can).

Next thing I can see is scalability. Make sure you don't rely on hard and fast numbers and try to keep your design flexible and agile.

Then make sure your code is understandable. Avoid magic numbers, proper documentation and naming are essential.

Answer 33

In VB.NET, I avoid using Parse like Decimal.Parse.

I use TryParse instead.

Answer 34

Don't use any of the new C# 4.0 features... it's like coding with "option explicit" turned off in VB. :) I joke, but seriously, some of these new features scare the crap out of me from a maintenance point of view.

Answer 35

Yup. The With statement is a throwback to Pascal, where it wasn't so harmful. It should have been removed from Delphi or reworked. Personally I don't agree with "with" statements (Pascal or Vb) they're sugar are are often misused e.g.

• You find yourself glancing (or worse paging) up more than once trying to figure out which object you're "With"
• You find a nested With (don't get me started).
• You find a block of old well maintained code, 20 lines long in a with block and - wait for it - the "with" object is null and is not used by any of the code (saw this about 2 weeks ago and laughed out loud - it was that or weep)

Other than "I'm not with with"

• Option Strict and Option Explicit MUST ALWAYS BE ON in Vb (I don't care if you can roll feature X in 30 minutes because it relies on late bindings where as it'll take a week if you've to write and implement a heap of interfaces because SWITCH THEM OFF AND YOU WILL LOOSE A FINGER)
• Don't Dim x as new Y in Vb6 (actually, don't use any VB6 feature if you can get away with it)
• C/C++/VB: Don't use Static variables in procedures
• C++ Don't use old ansi string handling LEARN THE STL

I known there's more rattling around in the back of the ould brain, I'll update this as I think of them

Answer 36

JavaScript one: never prototype against object.

Answer 37

In Java, it is possible to use generic types without to inform the generic parameters:

public class MyList<T> {
//...
}

public class Main {
    public static void main(String[] args) {
        MyList<String> a = new MyList<String>(); //OK
        MyList b = new MyList(); //OK, but should not
    }
}

Answer 38

SELECT *

It may be fine for ad-hoc queries, but should never be used in actual code. Always give a list of the columns you want in the order you want them in.

The Weak Reason: It's wasteful, as you almost certainly don't need all the columns.

The Strong Reason: Because you haven't specified the columns you want or the order you want them in, if anyone changes the natural column order or inserts a new column between 2 others, the code that extracts the information from the table will now be pointing to the wrong fields.

Answer 39

All forms of popular non-explicit lazy-up-the-stack error handling. People have trouble seeing the aftermath of their use is no different than the shunned GOTO command. Proper coverage is impossible to verify, perfect way to leak all manner of resources (even in garbage collected environments) and contrary to wildly popular opinion stack traces or low level messages simply passed up are ususally chunk full of nonsense which are not in any way useful to most developers let alone end users.

Answer 40

Never use autoboxing introduced in Java 1.5.

Integer i = getNumber(); // assume this method returns null
int j = i; // boink

There's really no good use for autoboxing unless you don't understand or don't care about the difference between objects and primitives - and then you better stay away from it anyway.

Answer 41

In Python, you should avoid running a bunch of methods on one line. I still do it, though.

"  hello\n\n".upper().replace('o','0').lstrip().rstrip()[::-1]

Answer 42

'extern' keyword in C.

C's linker doesn't check if the functions (or variables) match. The function is simply called or the variable used.

A contrived example,

// file1.c written by programmer A.
extern int function_b( void );
int num;
num = function_b();

// file2.c written by programmer B with no knowledge of programmer A.
static int global_b;
int function_b( void ) { return global_b; }

Now suppose programmer B changes function_b() to take a parameter. Or return an uint64_t instead of an int.

// contrived new file2.c
static uint64_t global_b;
uint64_t function_b( int caller ) 
{ 
    LOG_CALLER(caller);
    return global_b; 
}

We now have a corrupted stack and/or corrupted memory because programmer A's call to function_b() doesn't know function_b() has changed. The C compiler/linker doesn't check.

I see externs in cases where programmers take shortcuts. Instead of using the proper #include file, it's simpler to slap an extern into the code and hope for the best.

Answer 43

eval in the vast majority of cases in any language that has it (MATLAB, Javascript, etc). There are exceptions like parsing JSON if the input has been properly checked for validity.

It usually presents a security risk and there are often other ways to solve the desired problem. In MATLAB and Javascript there are facilities to get dynamic field names, e.g. if I have a structure S and it has a member somefield, and I have a variable containing the string of a field name v = 'somefield', then in MATLAB I can access this field with S.(v) and in Javascript I can access this field with S[v]. No need to call eval() in either place.

Answer 44

VB.NET has several "features" to maintain backward compatibility with older VB 6 code. Instead of using these "features" you should probably write your code to do things the .NET way.

Answer 45

In Python, multiple wild card imports:

from songsmith import *
from web import *

@publish
def create_bad_song(uri):
    return add_soulless_backing(get(uri))

It makes it difficult to find the source of a name when reading the code. Did get come from songsmith or web?

It is much better to say something like this:

from songsmith import add_soulless_backing
import web

@web.publish
def create_bad_song(uri):
    return add_soulless_backing(web.get(uri))

Answer 46

SQL: INSERT statement without a column list, i.e.

INSERT INTO foobar VALUES (foo, bar)

Immediately breaks when another column is added to the table.

Exception: In PL/SQL, a record variable can be declared by table%rowtype; it doesn't hurt to write something like

DECLARE
  v_foobar foobar%rowtype;
BEGIN
  v_foobar.foo := 'foo';
  v_foobar.bar := 'bar';

  INSERT INTO foobar VALUES v_foobar;
END;

Answer 47

The using keyword of C#.

Intead of destroying the object with a command, you have to follow the braces to find where it ceases existing. Does not decrease much the ammount of code you write, but decrease readbility a lot.