The Artima Developer Community
Sponsored Link

.NET Buzz Forum
Why static import is bad...

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Eric Gunnerson

Posts: 1006
Nickname: ericgu
Registered: Aug, 2003

Eric Gunnerson is a program manager on the Visual C# team
Why static import is bad... Posted: Jun 30, 2004 12:51 PM
Reply to this message Reply

This post originated from an RSS feed registered with .NET Buzz by Eric Gunnerson.
Original Post: Why static import is bad...
Feed Title: Eric Gunnerson's C# Compendium
Feed URL: /msdnerror.htm?aspxerrorpath=/ericgu/Rss.aspx
Feed Description: Eric comments on C#, programming and dotnet in general, and the aerodynamic characteristics of the red-nosed flying squirrel of the Lesser Antilles
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Eric Gunnerson
Latest Posts From Eric Gunnerson's C# Compendium

Advertisement

John Rusk asked me to elaborate on why I think static import is bad.

It's all about readability. Most people agree that the average line of source code is read far more times than it is written, which means that being able to understand the line is more important than being able to write it quickly.

Static import is bad because it adds an exception to the rules that everybody has to know and remember. If you see

int x = Process(s);

it's a line of code that's easy to understand, because you know what Process is, and more importantly, you know where to go look for it.

But if you add the capability of doing static imports, Process() can now come from other places, so you have to keep that in the back of your mind, and may have to traipse back to find the import statement. A good IDE could help out at this, but I don't think that should be a language design point.

One can argue that for its intended use - things like Math.Sin(), it will make things clearer, which I agree with. The problem is that I can see this feature being used by people who are familiar with their code to save time, and for them it's obvious that they've done that, but that's not true for the poor guy who inherits the code.

Any feature that comes with the kinds of warnings that were given at the introductions yesterday is questionable in my book, and I don't like adding something that has a good potential to be abused to address a case where people are doing the wrong thing already.

Of course, you can argue that C# has lots of areas of potential abuse, and I'd have to agree with you there, though I think the utility of those features is higher than merely saving a few keystrokes.

Read: Why static import is bad...

Topic: Threat Modeling book, Part 2 Previous Topic   Next Topic Topic: SQL Server 2005 Express Edition

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use