![Programming Programming](http://a.fsdn.com/sd/topics/programming_64.png)
![Books Books](http://a.fsdn.com/sd/topics/books_64.png)
![Media Media](http://a.fsdn.com/sd/topics/media_64.png)
![Book Reviews Book Reviews](http://a.fsdn.com/sd/topics/bookreview_64.png)
![IT IT](http://a.fsdn.com/sd/topics/it_64.png)
![Technology Technology](http://a.fsdn.com/sd/topics/technology_64.png)
Effective C# 233
Effective C#: 50 Specific Ways to Improve Your C# | |
author | Bill Wagner |
pages | 336 |
publisher | Addison Wesley |
rating | 9 |
reviewer | Jim Holmes |
ISBN | 0321245660 |
summary | Must-have addition to any serious C# developer's bookshelf |
If you're interested in, or currently working with, .NET and are tempted to skip past this book as Just Another C# Reference Book, think again. Wagner's book is a great resource because it covers concepts which run across the entire .NET Framework regardless of which language you're working with. While this book focuses on C#, VB.NET developers can benefit from some of the text within as well.
I also think this book speaks to a wide range of readers. Seasoned developers will blow through this content, fine-tuning their coding methods or starting new ones. Wagner specifically points out how practices experienced C++ developers may use aren't good practices in C#, such as avoiding function call overhead by writing longer C# methods with more convoluted loops. More on that later.
New developers also can greatly benefit from this book by using it to properly form development habits early in their careers. Examples of this might include following Wagner's recommendations for safe casting, strong use of interfaces, and knowledgeable resource management.
Wagner's writing style is clear and concise. He occasionally comes across as brusque, or as writing only to experienced developers ("I wouldn't write code like this and neither would you."), but those instances are few and far between. The rest of the book's voice is terrific. More important is the weight of Wagner's knowledge and experience.
One real drawback is a large number of typographical errors, sometimes several per chapter. Some sentences are missing content, and there are a large number of run-together words. These errors don't take away from the material, but it's an annoyance all the same. I would have expected better proofreaders at AW.
The book is well organized into six chapters, each hitting a specific area in C#. Within each chapter, Wagner covers six to ten items, each item focusing on one specific "minitopic," as Wagner calls them. Each item includes code snippets to demonstrate recommended approaches. Few of Wagner's snippets will function as standalone programs, but this is an advantage, as I see it. The book focuses on tight, specific examples, rather than weighing itself down with pages of extraneous fluff.
Often Wagner's recommended approach is contrasted against bad practices, or practices which might be optimal in other languages but work poorly in C#. An example of this would be Chapter 4's Item 31: "Prefer Small, Simple Functions," where Wagner shows how smaller functions are generally more efficient than larger functions with complex loops. This probably confounds experienced C++ developers, but it's a prime example of how valuable this book is. Wagner shows that .NET's Just-In-Time compiler pays less cost when calling functions than it does trying to wade through convoluted loop logic. His recommendation? Write "the clearest code you can create. Let the JIT compiler do the rest."
Chapter 1, "C# Language Elements", hits hard the topics "you must remember every day when you write C# code." This chapter discusses issues central to C#'s syntax, implementation and optimization. Wagner talks about basic Object Oriented concepts such as hiding class data members behind Properties (.NET's common access methods/fields via gets and sets), and why it's important to implement a ToString() method. Basic software engineering topics are also covered, like why it's important to differentiate between value and reference data types -- and the pitfalls of failing to do so. This chapter also thrashes out coverage on deep C# concepts like why developers should use foreach loops and why the GetHashCode() method will "practically always get you in trouble."
Chapter 2, ".NET Resource Management", has a lot of text on general patterns for constructing optimal code. Wagner's in-depth knowledge of the .NET Framework's underpinnings really shows through here. There's a very clear discussion of the performance ramifications of boxing (wrapping value type data into an object for method parameters) and unboxing. Minimizing extra garbage (unnecessary objects) and easing resource clean up via standard dispose patterns are also covered. This chapter's critical to ensuring you understand what's going on with resources in your .NET application.
Chapter 3, "Expressing Designs with C#", looks at object-oriented design in C#. While the discussion's specific to C#, there's a lot of great, practical information which applies to any object oriented development. Wagner gives some great examples with backup discussion regarding preferring the use of interfaces over inheritance and why it's a cleaner solution. (Java programmers who've read Alan Holub's "Why extends is Evil" in JavaWorld would enjoy this section.) There's also great treatment of using delegates for callbacks, and events for outgoing interfaces. Wagner also points out more pitfalls in a reference data type language: returning references to internal class objects via a read-only property (getter for Java folks).
Chapter 4, "Creating Binary Components", shows what critical topics you have to consider when creating even a moderately complex system for deployment. Wagner exposes some terrific details on how smaller is better when developing .NET assemblies for deployment. He also discusses why it's best to limit a class's exposure through public scope since this ends up advertising too much of your class's internals to potential users of that class. Wagner ties this back to interface discussions in earlier portions of the book, and makes a good case in this section for bad scope's impact on deployment.
Chapter 5, "Working with the Framework", delves into the .NET Framework Class Library. The FCL is a huge library and Wagner's insistent that too many developers are writing custom code for functionality which already exists in the FCL. This section helps to avoid having "developers reinvent the wheel." There are very useful discussions on using .NET runtime diagnostics, .NET's validation capabilities, and standard configuration mechanisms. Wagner also shows why .NET's reflection capability (one component dynamically discovering another component's capabilities at runtime) can be overused - but he also shows how to best use it in the appropriate cases.
Chapter 6, "Miscellaneous", is the catch-all section. Security and exceptions are covered here, as is the pain of working with COM interoperability - and why you should avoid it if at all possible. Just as importantly, Wagner points to several tools which should be in any C# developer's belt. He also identifies terrific resources available online.
What makes this book so useful is that Wagner constantly talks about the reasons behind why specific choices in C# should be made. For example, in Item 3, "Prefer the as and is Operator to Casts" Wagner moves through the rationale of why a developer should (when possible) avoid casting in C# and use the as and is operators instead. Casting can lead to headaches with data loss when casting a long data type to an integer one, or more headaches with the extra lines of code to ensure the cast was to a proper type. Sure, casts are sometimes necessary, and it's another value point for this book that Wagner gives clear examples of when his techniques don't apply -- and he also shows recommended alternatives for those cases.
It's just this kind of discussion from an experienced developer that makes this book so valuable. Good developers need to understand the ramifications of choices they make designing and implementing a system. Wagner's book is outstanding for exactly this kind of detailed, clear exposition.
An additional bonus: Wagner has a blog dedicated to discussion of items from his book. Erata are also listed there. See Bill Wagner's Effective C# blog.
The bottom line: this book really is a critical addition to a serious C# or .NET developer's bookshelf. It deserves a place right alongside books from McConnell, Macguire, Kernighan and Pike.
You can purchase Effective C#: 50 Specific Ways to Improve Your C# from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
So Call Me Old And Cranky (Score:4, Interesting)
But do we really need a "programming good C#" book? Isn't good programming all about, well, good programming? If I remember Code Complete correctly, it used pascal and C, I think. It definitely was one of the best books I've read, but how many times can you say the same thing over and over again?
Languages come and go. But good coding techniques don't dependent on a certain vendor or technology.
Maybe this is a good book if you don't know much of any programming language and want to pick up C#. Speaking as a C# developer who does Java, C, C++, and VB, I just read some of the rags and jumped in. Then when I wanted to do something else, like create a custom web control, I got a book in C#. Presto/Bingo, I'm coding in C#. OOP as a concept is going to have similar constructs, no matter what the language, right?
Sorry for the rant. It's probably a great book. I just don't understand how good coding practice is dependent on the flavor-of-the-week. Perhaps in his comparisons the reviewer does a disservice to the intent of the work.
Re:So Call Me Old And Cranky (Score:5, Insightful)
Someone may be an expert at high-level OO design, but when it comes to programming in C++ specifically, he might not know about things like the utility of auto_ptr, that it's a bad idea to throw an exception from a destructor, why destructors should often be virtual, dangerous cases where an unexpected temporary object might get created and changed instead of the intended one, etc... That was where the value of the Effective C++ books was for me.
Re:So Call Me Old And Cranky (Score:2)
C++ is a high-wire act without a net, no doubt. But more "polished" lanugages, like Java and C# keep the sharp objects away from the developers. Some of those issues you mention are truly gnarly -- and you can get in a world of trouble with C++ code. You can still cut your foot off with Java, but you have to saw at it a little more. My two cents only.
Can chickesn swim? Find out now! [whattofix.com]
Re:So Call Me Old And Cranky (Score:3, Insightful)
And knowing the language. Sometimes there's idioms in a language that just aren't obvious. Like the use of "explicit" to prevent C++ from surprise autocasts, or what const correctness really means and how to avoid breaking it. Or when to explicitly null references in Java to get them gc'd, and when it hurts performance (this idiom changed when Java's gc algorithm changed).
C# no doubt has al
Re:So Call Me Old And Cranky (Score:2)
On the good side of things you have things like assemblies, the checked and override keyword, meta-data and things like that. These are pretty language specific, and you would need to learn them before becoming a moderate or expert pro
Re:So Call Me Old And Cranky (Score:2)
Well, if you found that astounding, you probably need to get out more :).
Seriously, it's more of a mundane language decision than something to be astounded about. Coming from C++, when I read that Java methods were all virtual, I thought, "Ok, I see what they're doing there." But by no stretch of the imagination did it astound me.
Re:So Call Me Old And Cranky (Score:2)
Well, it makes sense on some level, but it's not relevant to the topic...for some reason my mind had decided that the thread had got onto Java/C++ differences. Must sleep.
Re:So Call Me Old And Cranky (Score:3, Interesting)
You know, I would venture to say not all programming concepts are necessarily always universal. That's because programming languages are abstractions, and abstractions can vary vastly.
Take an elementary operation: You might say a for loop is a for loop, but in languages like LISP we tend to use recursion.
In MATL
Re:So Call Me Old And Cranky (Score:2)
Alas, no matter how smart programmers think themselves today, it's incredible to see how many people can't compute longhand with a great deal of speed and accuracy. Spelling, grammar, and punctuation are considerably worse, but without their hardware, most are pretty weak all of the way around.
Re:So Call Me Old And Cranky (Score:2)
Re:So Call Me Old And Cranky (Score:2)
Sapir Whorf hypothesis (Score:4, Informative)
Sapir-Whorf and programming languages [wikipedia.org]
Re:Sapir Whorf hypothesis (Score:2)
Academically, perhaps this is an area worth further study. Pragmatically, however, it's the equivalent of saying fat people prefer bigger belts. True, but uninformative, imo. Plus. I never liked Whorf that much anyway. H
You Are Old And Cranky (Score:2)
The basic concepts, yes. How the platform or language treats things, not necessarily. Here's a specific OOP example between the latest so called "fad" languages. In Java methods are implicitly virtual. In C# you have to explicitly declare a method as virtual. Prescriptive guidance as to how one should go about determining which methods to mark as virtual is only relevant to one of these languages. So while you are cor
Here's the blog... (Score:3, Informative)
Get a design patterns book (Score:2, Insightful)
Design Patterns are the symptom of a problem (Score:2, Interesting)
Paul Graham said it best [paulgraham.com]:
Rails? (Score:2)
Re:Rails? (Score:2)
ActiveRecord in Rails is based on...Fowler's ActiveRecord pattern, and it is implemented using SingleTableInheritance pattern for the data persistence side of things, too (but it would be nice if one could get it to do multiple table inheritance as well just as easily).
Re:Design Patterns are the symptom of a problem (Score:2)
Use patterns to solve well researched problems, but never code to a pattern.
Re:Design Patterns are the symptom of a problem (Score:3, Informative)
If you want to really understand design patterns, there's really no way
Re:Design Patterns are the symptom of a problem (Score:3, Insightful)
The idea behind good patterns is to reduce common coding occurances into a generic pattern. Sort of a meta code reuse scheme.
Rather than focusing on rewriting a stack or queue from scratch, you just use something called a stack or queue (more generically, a "list") that functionally does the operations, i.e., push, pop, swap, count associated with what you want to use. You don't care if it's implemented as an array, a linked lis
Re:Get a design patterns book (Score:2)
It's disappointing that the C# Programmer's Reference, by O'Reilly, still doesn't pay any homage at all to other coding environments. If I wanted a VS.Net reference, I'd buy one. I just want a C# reference, to which it is, for about 3/4 of the book.
Re:Get a design patterns book (Score:2)
review left out important point (Score:5, Informative)
Re:review left out important point (Score:2)
In the same class as code complete? (Score:4, Informative)
On the other hand, it has proved useful as a talking point in our reading group (a mix of professional programmers ranging from fresh grads to seasoned vets). As for the C# book, well we could do with a good reference for the language (although a decent c++ book and a little java and
Re:In the same class as code complete? (Score:2)
I think I know what you are saying, but I want to add my own 2 cents...I've had the opportunity to work with code written by three types of software developers:
Group A: rank novices. The ink on their comp. sci. B.S. from Somewhere State University is barely dry. They can code an abstract linked list class, but are clueless as to how to intelligently design and construct a non-trivial application with mai
large functions in c++ (Score:5, Insightful)
Often Wagner's recommended approach is contrasted against bad practices, or practices which might be optimal in other languages but work poorly in C#. An example of this would be Chapter 4's Item 31: "Prefer Small, Simple Functions," where Wagner shows how smaller functions are generally more efficient than larger functions with complex loops. This probably confounds experienced C++ developers, but it's a prime example of how valuable this book is. Wagner shows that
I don't know how he got the impression that experienced C++ developers would be confounded by short functions. By using short inlined functions, C++ developers don't pay any cost by breaking up large routines.
Re:large functions in c++ (Score:3, Interesting)
It's funny how they hype the features of new programming languages, while they seem to miss what is already in C++. Personally, i can't really take seriously a language without proper template support.
Re:large functions in c++ (Score:2)
Re:large functions in c++ (Score:2)
Re:large functions in c++ (Score:2)
Wow, look at all the MS haters ... (Score:5, Interesting)
It's no joke, and I'll be buying this book just to have it. I've also picked up most of the Deitel series of books on c#, and of course the O'reilly books. The c# cookbook is another GREAT reference. Anyone interested in starting with C# should check www.codeproject.com for examples. Also, along with a rude admonishment to the MS haters for not having researched the topic (MS dependant indeed), check www.omnicore.com for a native crossplatform compiler for c#. It's cheap too, but doesn't do forms support just yet (when it does, I'll probably move from VS just to get free cross-platform compatability).
-chitlenz
Re:Wow, look at all the MS haters ... (Score:3, Funny)
Say... If you were to rewrite it in C++, would you have spendt 8 years or closer to 6 months?
Re:Wow, look at all the MS haters ... (Score:4, Interesting)
-chitlenz
Re:Wow, look at all the MS haters ... (Score:2)
Sure, you write nice app, that run in Linux, them MS pull the licesing for non windows, and then all the nice linux stuff will only be allow to work on the MS boxes.
And yes, I have worked in the
VS sucks, but that is a different issue. Of course have a project that compile a dll larger then 100K can cause reference issues. the VS and C# camps point at each other for this one. I think it's a c# issue becasue it doesn't happen in V
Re:Wow, look at all the MS haters ... (Score:2)
2) Mono is NOT smoke and mi
Re:Wow, look at all the MS haters ... (Score:2)
Err WHAT are you talking about?? I to have been doing
The project I'm working on currently (windows client) has an EXE and 22 DLLS, totalling over 8mb. there are a 3 DLLs over 1mb, and one over 2mb.
Never seen or heard of the problem you're describing. VS can be a bit flakey at times, but I've got nothing but praise for the
Re:Wow, look at all the MS haters ... (Score:2)
C# is a nice language. A very refreshing change of pace from C++.
-John
Re:Wow, look at all the MS haters ... (Score:3, Funny)
Thank you, Guido!!!
Re:Wow, look at all the MS haters ... (Score:2)
I admit to having fairly ignored Java, after dealing with Sun for several years, and being fed up with having it rammed down my throat by both th
Re:Wow, look at all the MS haters ... (Score:2)
The MS dependency is not on C#, but on VisualStudio.
C# Book (Score:2, Funny)
It teaches u how to program in the first half and in the second half it has references to all the libraries.
I find C# pretty straight forward if u know Java.
I love programming in languages that have their own memory management. Worrying about pointers and what not takes away so much time from productivity. For ppl who wanna get hardcore and want control. Yes u can embed Assembly in ur C# code.
Now if only someone makes microcontrol
Been using it since it was released and Love It (Score:2)
Ethics (Score:2)
Visual Studio & .NET are getting better! (Score:2, Insightful)
end-disclaimer.
The MS bashing is quite disturbing. Well i know that
While i may have made myself flamebait, i think
from the oxymoron dept... (Score:2, Insightful)
[mod me +5 funny like the parent. What's that? You don't like underhanded my-langauge-is-better-than-yours jokes, meant to enflame rage between already volatile communities? Oh, sorry, mod me down then.]
Re:from the oxymoron dept... (Score:5, Interesting)
C# is an advanced, well thought-out OOP language. When coupled with the
It's an open standard, despite what people may think, and as Windows.Forms becomes implemented on other operating systems, adoption will spread. Microsoft even released the source code to a FreeBSD CLR implementation called "Rotor".
Remember, just because it's from Microsoft doesn't automatically negate it
Re:from the oxymoron dept... (Score:3, Interesting)
(This brought to you by one of FreeBSD's Mono port maintainers.
Re:from the oxymoron dept... (Score:4, Interesting)
Re:from the oxymoron dept... (Score:2)
But the thing that worries me most is the IDE. For C# I know two moderately usefull IDE's: Microsoft and Borlands. Both are commercial (ok, maybe not for students, but you know about indoctrination). So we either have to pay these companies for their environments, or we should use the rather outdated text editors for t
Re:from the oxymoron dept... (Score:2)
Re:from the oxymoron dept... (Score:2, Interesting)
Actually, I've heard far more people knowledgable in both languages say the exact opposite as this. Considering C# was developed supposedly to "fix" specific deficiencies in Java and I've seen good rebuttal on both sides with Java coming up on the short end of the stick almost all the time (exception cases are where
Re:from the oxymoron dept... (Score:2)
The information is there, but because the
MS' documentation has arguably gone downhill over the last 10 years or so. They have focused more on the tool (new help engine vs Winhelp4) and the file format, and not the quality of what is in the CHM f
Re:from the oxymoron dept... (Score:3, Interesting)
The only difficult thing I've found with the
Rotor license terms? (Score:2)
Under what terms?
Re:Rotor license terms? (Score:3, Informative)
Re:Rotor license terms? (Score:2)
Ah. "Non-commercial-use". And they have the gall to complain about the GPL (me, I'm a BSDL fan, but I can live with the GPL... but I'm not touching no-commercial-use source with a 10 foot non-conductive thermally-stable shock-dampened safety-breakaway pole.
Re:from the oxymoron dept... (Score:2, Insightful)
But its not an open platform if you've got a submarine patents laying around. I feel a bit superstitious about saying this - but I just don't trust Microsoft enough to be in control of the tools I use for my livelihood (programming for cash).
My attitude may change, but in the past my experience has shown me its not worth it.
Given that, I'd rather learn Ruby on Rails
Re:from the oxymoron dept... (Score:4, Informative)
There are also tons of other problems I have run into with the .Net framework over the last few years. Here is a _major_ problem for me that I just posted about [slashdot.org].
Re:from the oxymoron dept... (Score:2)
Basically, because MS's windowing system is not in other OSes, everything behind the interfaces needs to be reimplemented. Only if MS changes the interface do they break compatibility, and, by doing that, they'd break compatibility for all Windows programmers, too.
Re:from the oxymoron dept... (Score:2)
Re:from the oxymoron dept... (Score:2)
Wrong (Score:2)
So far, other than low-end schools or schools with millions being thrown at them from MS, few in academia are adapting it. ACM and the major 4 universites backs Java as the primary language for CS.
Likewise, set aside the fact that nothing inovative has come from C#. I will grant that one day something might, but after 5 years nothing yet.
the real problem is the Gnome world was foolish enough to adapt it. Now, MS is finally throwing the patent s
Re:Wrong (Score:2)
C# rips off from Delphi/Object Pascal as much as it does from Java...
Gee, I wonder...didn't Microsoft seriously poach hard on Anders Heilsberg (sp) and a couple of other key Delphi developers, to the point that Borland sued MS for unfair competition?
OOP languages tend to be pretty poor. (Score:2)
Secondly, OO programming is inherently parallel, as you access everything by implied reference, all data is stored on the objects, and all communication is by very controlled, specific paths. But multi-threaded OO code tends to be horrible to write, whether in C#
Re:OOP languages tend to be pretty poor. (Score:2)
Unfortunately, the only language that is even close to pure OO is Smalltalk
And the last time you looked at Actor or Eiffel was?
Re:OOP languages tend to be pretty poor. (Score:2)
What academia had anything to do with COBOL, a language created for the United States Department of Defense?
Re:OOP languages tend to be pretty poor. (Score:2)
Please don't be so fucking ignorant. What you're referring to is called Indigo, and it's a messaging stack that will also be available for Windows XP and 2003. It is not an "extension to C#". It's not even part of .NET, although it's mostly written with it and designed to be used by applications written with the framework.
Further, Novell has said they were not interested in implementing Indigo, and will not. Ever. That Indigo is encumbered by patents does not change the
Re:from the oxymoron dept... (Score:2, Insightful)
So is C++. Why eliminate the standard programming language in favor of another? You know Microsoft didn't just develop it out of the goodness of their hearts. It was a business decision that will be good for Microsoft and bad for programmers. That is, unless you like learning yet another redundant programming language.
Re:from the oxymoron dept... (Score:2)
One of the problems I have with C++ is the calling of functions with reference arguments. If you're unfamiliar with the function being called, you can't tell,
Re:from the oxymoron dept... (Score:2)
Microsoft can change anything they want in C#, and bet they will.
Re:But does it... (Score:3, Insightful)
Re:But does it... (Score:2)
Re:But does it... (Score:3, Informative)
And before you say its an ECMA standard- ECMA does not require standards to be unencumbered, or even to be licensed on a RAND basis.
Re:But does it... (Score:2)
Give me a break... at least with C#, it's an ISO and ECMA standard. Further, Microsoft has explicitly permitted 3rd party implementations of the
But I'm not going to get into a petty langauge war. Use the right tool for the job, if it's C# or Java, frankly it matters little. Only zealots think otherwise.
Re:But does it... (Score:2)
Re:But does it... (Score:2)
Frankly, most companies (including the one I work for) choose to support the most widely used OS; supporting multiple OSes means more testing, more development costs. And for Windows, C# blows away Java.
But again, I won't get sucked into a langauge debate. If I were to write cross-platform software, I might choose Java over C#. It's all about getting the right tool for the job.
Re:But does it... (Score:2, Informative)
Joke aside, that's the question I was asking myself. Why learn a platform specific language when you can use a platform independent language like C++, Java or Ruby?
Windows is wonderful (well, not really), but there are other platforms out there as well.
Re:But does it... (Score:2)
C# is not platform specific. However, the
That said, the Mono Project [mono-project.com] allows you to write code in any
Re:But does it... (Score:2)
When did java become platform independant? (Score:2)
Re:Hah (Score:4, Insightful)
You don't like
Re:Hah (Score:2)
What? Didn't you read the EULA when you registered with Slashdot?
In all seriousness, the
Re:Hah (Score:3, Interesting)
I am not a .Net hater, I am just an MS hater. Why? Because of the intentional things MS does to stop other products from working. For example, ASP.Net (in C# or whatever) should put out standards compliant HTML, regardless of browser. However, that is not t
Re:Hah (Score:2)
Re:Hah (Score:2)
Re:Hah (Score:2)
Re:Hah (Score:4, Interesting)
I myself am a C# developer (win forms and web forms), and I initiall had a huge problem trying to test and use any sort of aspx web application in firefox. After poking around for a bit, it turns out that the
Anyway, there is a section that you can place in you web.config or machine.config files (i assume you know the difference between the two) that details the browser capabilities of various browsers hence the name browsercaps. By default this section of the file is pretty useless, it will detect IE, some netscape and that more or less it. Maybe some mobile browsers for PocketPC as well. This can be updated, and i find that the information at This Link [slingfive.com] is extremley helpful. I have used the browsercap information from this site on a few production servers to get rid of some ugly issues with AbleCommerce and Firefox, and i have it on my development machine as well; the difference in rendering will suprise you. In short, I highly reccomend that every ASP.NET developer check this information out, and keep your browsercaps section up to date. It may not be a 100% effective solution but it does do an excellent job of getting rid of most of the problems you will have when using a non MS browser.
Re:Hah (Score:2)
I will try to play around with the browsercap stuff some more. As I pointed out in my post, if you set Firefox to pretend to be IE, the HTML usually displays _much_ better, however the Javascript gets all crappy and non-s
Re:Hah (Score:2)
Yes, IE is more at fault than FF/whatever, but lots of people use it and if you are writing web apps you should know to test with different browsers. As other posters have mentioned, you can specify to a great extent how to render pages in differenct bro
Re:Hah (Score:2)
I agree with you and this is the approach I take. However, my friend (who is a really nice guy) grew up with MS only tools under MS only OSes. So to me he is typical of all the "MS Developers" that I have met. They have never been exposed to non-MS stuff and are not familiar with it. I have found that it is hard to teach these type of programmers about standards and
Re:Hah (Score:2)
Re:Hah (Score:2)
Re:Hah (Score:2)
Re:Meanwhile... (Score:3, Interesting)
Re:Hah (Score:2)
You just gotta go with it. It's not go
Re:Hah (Score:2, Funny)
Re:alright ! (Score:2)
What if you really don't need to run on multiple platforms?