William Clardy wrote:

Lastly, I question whether code is really any better when you take a 12-step chunk of linear (a.k.a. "spaghetti") code and refactor it into a 3-step process with each step having 4 layers of abstraction in the form of calls to other functions. I would say that there are many occasions where spaghetti code is more readable to both the human and the compiler.

If it's code that works on only one layer of abstraction that's a bit longer, maybe like a stupid init routine for some hardware device in an embedded project, okay. If that routine jumps between different levels, breaking it down into small functions will make it more understandable, because that untangles complexity which would otherwise have to go into your head all at once / you'll have to orient yourself in that complexity first. Whereas breaking it down into smaller chunks, you're basically outlining a graph of how things work.

I like my AKG K-271 MKII for exactly that purpose - with the alternative ear pads of fluffy stuff (not the artificial leather ones), I can wear them for hours. They are self-adjusting (it does work), very comfy, and sound great (for closed-system cans, which is what you want in your scenario) They helped me survive in a game company with 30 or so people in one giant room, no walls to the kitchen area with huge coffee grinder, elevator opened directly into the room, wooden floor with some people having noisy shoes... Let me add that I am not one to crank his music up to ear damage levels. The phones do dampen outside noise somewhat. Alternatively, try soft silicone ear-plugs. Like Alpine "Sleep Soft" for only moderate reduction. Be sure not to show the packaging to your boss, there could be misunderstandings. :-D I wear those every night, so I guess you won't be uncomfortable wearing them during working hours. They last about a year if you clean them once in a while. There are similar types of ear plugs with more "discs" than two which reduce noise more, like those made for concerts. I don't remember a particular product.

"The book". BEEEEP. Wrong question ;-) I very much doubt that you'll find a book that has "languages for various devices/instruction sets." in it - well, current, modern ones anyway. The programming guide on the ARM cortex M3 is a rather thick book already - and that's only generic onformation, not talking about the custom peripherals of any of the different hardware implementers at all. One book, or even many books by themselves won't turn you into an "embedded C developer". What do you mean by "C embedded"? I'm doing some embedded work only for a few years now, but I think some sort of restricted C for embedded stuff is a thing of the past. Even most commercial embedded IDEs at least for the ARM world use GCC, well and then there's the ARM compiler that comes with Keil, also standard C. If you mean "c programminc concepts best suitezd in embedded world", hrm, maybe look at the book called "design patterns for embedded systems in C", although reviewers found some flaws with the way the book is made / usability, albeit good content wise. There are quite some very different architectures on the market. I doubt a book can cover them all well enough for you to become proficient. You need to do stuff and gain experience. Sounds obvious, yeah. But maybe pick one popular architecture, and try to understand that one and actually do projects with it, fail and learn why, learn by doing. There may be a book teahcing general concepts - but then again, take just the GPIO (general purpose input / output) - what they are and can do also differs between architectures. Yeah, I'd definitley suggest that you find some clever way of findong out what are well in-demand "hot" platforms / architectures right now and then pick one that may be the most beginner friendly one from freely available resources - you'd have to ask for that specifically then. I know that e.g. AVR is supposed to be simple, and they even offer a free to use VisualStudio based IDE I think. For some, AVR is too simple / not capable enough. (the small AVR, not the AVR32 anyway) I like the STMicro electronics based ARM cortex chips since they have some nice ranges which cover my project needs better than other ARM implementors I checked out so far, or other platforms. But some people think this is harder to get into micro controllers than other MCU types. They are option-packed & lots of stuff needs to be set up. Ok my overall view of MCU platforms is limited, let's see what other people have to say. Maybe you should look for a dedicat

Fabio Franco wrote:

Well, we have a whole Code Horrors section on code project because language designers cannot prevent bad use of a language.

Yeah I know that language design, or the design of anything for that matter, will not yield perfect and guarandteed fool-proof concepts just when something new is introduced. Still I have the impression that the C# team knows what they're doing (although some people complain about this or that, or that new things like functional langue concepts are included... :-D ) I found this MSDN page: http://msdn.microsoft.com/en-us/library/bb384061.aspx[^] containing the section: _"The var keyword can also be useful when the specific type of the variable is tedious to type on the keyboard, or is obvious, or does not add to the readability of the code. One example where var is helpful in this manner is with nested generic types such as those used with group operations. In the following query, the type of the query variable is

IEnumerable>

. As long as you and others who must maintain your code understand this, there is no problem with using implicit typing for convenience and brevity."_ So, while they do hint at this usage could be a disadvantage for maintenance, they agree that it doesn't have to - if it's no problem for anyone in the team. Still, if there may other members being added to the team some point later, this may change, and the guy may have a little harder start ^^ While it'd be crazy to try to guard against anything that may or may not happen in the future, and should do what works best for the current team, I think, I now do get the feeling that perhaps it's not too bad an idea to not go too crazy with the var thing. But it's quite interesting, any way. I guess I'll examine some of my code and see how I'm really using it heh :-D And whether the types may be obvious, e.g. because say, in a function that takes a few "decimal" parameters, and only calculates some stuff with decimal all the time, it should not be too hard to figure that all the var stuff in between would be decimal, too. I think this is actually the main occurence of my "var", besides queries of course (which I mostly use for non-database stuff because, laziness can be good :-D )

Well, to make it a bit shorter here, I'll certainly have some thoughts about the severity of readability by slower type deduction. I've haven't heard complaints of colleagues so far, but let's see when asking them directly about it. Though, that the purpose of the var keyword, as intended by the language designers, is solely for anonymous types - I have to agree even less now, seeing how common place it is in examples in the language specification document. Not only should they have refrained from such examples if they didn't intend for it being used such ways, but actually they could easily have restricted the use of the var keyword for ananoymous types (you suggested a warning there). If it's so glarinlgy obvious how "bad" this is, I think they otherwise careful language designers would have seen it themselves. As fiercely as some people here claim that anon types is the "actual only intention" for this - it now seems even more like pure opinion and taste. Just like curly braces position... which people fight as fiercely over, heh.

Well, the numerous examples using it other ways, in the C# 4.0 language spec file, seem to disagree there.

Btw., I just skimmed through the C# 4.0 language specification, and it is littered with examples like:

var contacts = new List

Do you think the language designers would have used examples like that if they thought using the "var" keyword that way was bad, or against their very own intentions?

Fabio Franco wrote:

Do you really think that Ctrl+C, Ctrl+V is a painful typing exercise. Better yet, do you really think that, Ctrl+C, Ctrl+V is too much for the sake of readability? Most C# people look at the beginning of the line to verify a type (or a base type/interface). Having a var there will not help at all when one is quickly sweeping the code.

Ctrl+C, Ctrl+V and jumping around... come on, it still disrupts the flow and is quite a PITA. Sweeping, well, depends on how quickly, I guess, since my IDE shows the type of a variable when hovering the cursor over it, which happens to be where I read when scrolling. There are languages which don't have something like LINQ but do have automatic type inference, so a lot of people seem to disagree here what such a feature is good for or isn't. But yeah, I can see how that can be annoying - I have the problem with code where people put the opening { brace at the same line instead another one :-D I hate it when I can't identify scope by looking at the exact same column, but have to search for it in variying line widths... With my usual assignment style var use, though, the type is still quite to the left - if there is a very long variable name, I might put the type in the next line, a bit intented.

Fabio Franco wrote:

You don't use dynamic keyword for types known at compile type, do you?

Huh? Var is not dynamic. Bad example? Exactly *because* the type is known at compile time, I do use var in assignments!

Fabio Franco wrote:

Somethings are there for a purpose, so that's what we should use them for

That sounds quite like a priest, talking dogma, not to be questioned. If something turns out to work quite nicely for something else than original intention, why not use it? That something was not originally envisioned to be use for something, alone, is not an argument at all, for refraining from using it that way.

Fabio Franco wrote:

Do you use a hammer as a screwdriver? You could bust something open, but I'd rather not brake it while doing so.

I have not seen an example of this var use busting something open, other than you personally can't read the code as quickly.

Fabio Franco wrote:

OriginalGriff has more experience than both of us combined, i

In what way is "laziness" bad, concerning typing? Who needs typing excercise? I cringe at the sight of redundancy, and mentioning the type twice in an assignment is redundant. "In my opinion var should only be used to infer anonymous types and nothing else" And how do you rationalize that? Because you think it was made for something else, and should be used only there? It's your personal taste, other than "should.. blah blah", "beginners blah blah" I've heard no sensible explanation of you. Now I don't claim to be a genious programmer, but I'm "in the field" as long as you are plus some small extra years, although not knowing every aspect of every language I need to use. Still I'm quite confident that if there was a really dangerous issue with "using var outside of LINQ", I would have noticed it, I guess I'm experienced enough for that. I just don't see any, from none here who commanted about that, just loads of personal taste statements...

sure autocomplete... it's still shorter than that, and actually I don't want to *read* all that much redundancy in a line of code, it's just plain idiotic to mention the type twice when the compiler knows anyway. Actually this is a thing I always hated about C and C++, because it seemed stupid, that I had to repeat myself although the damn compiler *should know* by assignment when creating a variable.

[quote]I'd just like to add that it was made for Linq because Linq generates a lot of anonymous types. It would be a hell to create classes for all possible result sets.[/quote] Sounds like it makes sense. But "was made because of LINQ" sounds then more accurate than "made *for* LINQ", since automatic type inference is surely useful in other contexts.

ah, you mean the using ^^ Haven't seen this usage of it, wow, yet another meaning of the keyword "using", I think now that's quite an abuse... (language design wise)

I think I do: automatic type inference. Which is what my example used them for.

I don't think it was made just for LINQ, that's not what I've read in countless introdution texts about new features back then. What do you mean by "Except that generics cme later" ? Generics are there since .NET 2.0, var since 3.5 IIRC.

haha sounds like me. var is certainly not only nice for foreach loops or LINQ. I find it rather stupid to type something like:

Dictionary>> stuff = /*sigh*/ new Dictionary>>();

Yes, stupid indeed. And it's exactly that type of scenario the "var" keyword was made for.