13.07.2015 Views

C# in Depth

C# in Depth

C# in Depth

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

214 CHAPTER 8 Cutt<strong>in</strong>g fluff with a smart compilerobvious the return type is just from look<strong>in</strong>g at the call. Integer literals are anotherexample where guess<strong>in</strong>g the <strong>in</strong>ferred type is harder than one might suppose. Howquickly can you work out the type of each of the variables declared here?var a = 2147483647;var b = 2147483648;var c = 4294967295;var d = 4294967296;var e = 9223372036854775807;var f = 9223372036854775808;The answers are <strong>in</strong>t, u<strong>in</strong>t, u<strong>in</strong>t, long, long, and ulong, respectively—the type useddepends on the value of the expression. There’s noth<strong>in</strong>g new here <strong>in</strong> terms of thehandl<strong>in</strong>g of literals—<strong>C#</strong> has always behaved like this—but implicit typ<strong>in</strong>g makes it easierto write obscure code <strong>in</strong> this case.The argument that is rarely explicitly stated but that I believe is beh<strong>in</strong>d a lot of theconcern over implicit typ<strong>in</strong>g is “It just doesn’t feel right.” If you’ve been writ<strong>in</strong>g <strong>in</strong> a C-like language for years and years, there is someth<strong>in</strong>g unnerv<strong>in</strong>g about the whole bus<strong>in</strong>ess,however much you tell yourself that it’s still static typ<strong>in</strong>g under the covers. This maynot be a rational concern, but that doesn’t make it any less real. If you’re uncomfortable,you’re likely to be less productive. If the advantages don’t outweigh your negative feel<strong>in</strong>gs,that’s f<strong>in</strong>e. Depend<strong>in</strong>g on your personality, you may wish to try to push yourself tobecome more comfortable with implicit typ<strong>in</strong>g—but you certa<strong>in</strong>ly don’t have to.8.2.4 RecommendationsHere are some recommendations based on my experience with implicit typ<strong>in</strong>g. That’sall they are—recommendations—and you should feel free to take them with a p<strong>in</strong>chof salt.■■■■■■Consult your teammates on the matter when embark<strong>in</strong>g on a <strong>C#</strong> 3 project.When <strong>in</strong> doubt, try a l<strong>in</strong>e both ways and go with your gut feel<strong>in</strong>gs.Unless there’s a significant ga<strong>in</strong> <strong>in</strong> code simplicity, use explicit typ<strong>in</strong>g. Note thatnumeric variables always fall <strong>in</strong>to this category s<strong>in</strong>ce you’d never ga<strong>in</strong> morethan a few characters anyway.If it’s important that someone read<strong>in</strong>g the code knows the type of the variableat a glance, use explicit typ<strong>in</strong>g.If the variable is directly <strong>in</strong>itialized with a constructor and the type name is long(which often occurs with generics) consider us<strong>in</strong>g implicit typ<strong>in</strong>g.If the precise type of the variable isn’t important, but its general nature is clearfrom the context, use implicit typ<strong>in</strong>g to deemphasize how the code achieves itsaim and concentrate on the higher level of what it’s achiev<strong>in</strong>g.Effectively, my recommendation boils down to not us<strong>in</strong>g implicit typ<strong>in</strong>g either“because it’s new” or for reasons of laz<strong>in</strong>ess, sav<strong>in</strong>g a few keystrokes. Where it keepsthe code tidier, allow<strong>in</strong>g you to concentrate on the most important elements of thecode, go for it. I’ll be us<strong>in</strong>g implicit typ<strong>in</strong>g extensively <strong>in</strong> the rest of the book, for theLicensed to Rhona Hadida

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!