Why Microsoft Developers Need a Style Guide

Obviously it is... by Anonymous Coward · 2012-02-12 10:34 · Score: 4, Funny

You silly open source GIMP developers...

When loading a kernel module... by Anonymous Coward · 2012-02-12 10:34 · Score: 5, Funny

Cancel, or "pimp this bitch"

Re:When loading a kernel module... by flyingsquid · 2012-02-12 13:02 · Score: 5, Funny

"It looks like you're trying to write a letter expressing your dissatisfaction with an escort service. Would you like help trying to bitch out this pimp?"

I have an idea for the style guide by Anonymous Coward · 2012-02-12 10:36 · Score: 5, Insightful

How about, when naming variables, you have to put the first letter of the typename in the start of the variable name!

And then later let's change the types in the API but keep the unmatching old names for compatibility!

Re:I have an idea for the style guide by skids · 2012-02-12 10:54 · Score: 5, Funny

I don't know, I found the chapter on EnterpriseInterfaceThunkClassEnterpriseGeneratorCOMParameterInterfaceThunk32 COM_Enterprise_Enterprize_ENTERPRISE very illuminating.

--
Someone had to do it.
Re:I have an idea for the style guide by exomondo · 2012-02-12 11:08 · Score: 2

How about, when naming variables, you have to put the first letter of the typename in the start of the variable name!
Hungarian notation isn't about using the typename at all.
Re:I have an idea for the style guide by maxwell+demon · 2012-02-12 11:23 · Score: 5, Insightful

How about, when naming variables, you have to put the first letter of the typename in the start of the variable name!
Hungarian notation isn't about using the typename at all.
Please tell that to Microsoft.

--
The Tao of math: The numbers you can count are not the real numbers.
Re:I have an idea for the style guide by exomondo · 2012-02-12 12:42 · Score: 2

If it's stronly typed, there's no sense it adding this to the variable name: use a better IDE if you don't know what a variable is at a certain point.
No, there would be no sense adding it if it were the typename, but it isn't. For example a long representing the column width isn't lColWidth or lWidth it would be colWidth because it's the 'kind' (since people often interpret 'type' in this context to mean 'typename') of thing being represented, not the way it is being represented.
Re:I have an idea for the style guide by TheRealMindChild · 2012-02-12 12:57 · Score: 2, Informative

As an old classic Visual Basic programmer, there was a good reason to use hungarian notation. You had a sorted dropdown list of the classes/types, from which after choosing one, could then choose the method/property to implement in an adjacent dropdown list. Point being, your textboxes were grouped together and your enums were grouped together, and so on. It made managing the code easier.

--

"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Re:I have an idea for the style guide by Rinikusu · 2012-02-12 13:11 · Score: 5, Informative

There were a lot of who went through college in the early-mid 90s where Hungarian notation was considered proper software development and scores were marked down in various programming classes if you didn't adhere to it. It was the late-90s/early-2000s when people apparently discovered that it was a very, very bad idea especially as we refactored 5-10 year old code. Now it seems we're happy if you just use camel-case.

--
If you were me, you'd be good lookin'. - six string samurai
Re:I have an idea for the style guide by jd2112 · 2012-02-12 14:17 · Score: 2

How about, when naming variables, you have to put the first letter of the typename in the start of the variable name!
Hungarian notation isn't about using the typename at all.
Please tell that to Microsoft.
Even Microsoft has given up on Hungarian Notation.

--
Any insufficiently advanced magic is indistinguishable from technology.
Re:I have an idea for the style guide by NevarMore · 2012-02-12 14:50 · Score: 5, Insightful

I was (am?) the generation who learned to code in the mid-90s. I hate to sound lazy, but once we got over that hungarian nonsense, every team I've worked on just agreed (or had dictated) an autoformatter for our IDE and just made sure to run it before we committed. Hell one team had it setup as a pre-commit hook in SVN. It mooted many of the style arguments and let us focus on solving real problems.
Hell the more modern IDEs like Eclipse, IntelliJ, and VisualStudio even suggest variable names and hint for proper case. As programmers and software engineers should we not use software tools to do tedious and mundane work for us?
Re:I have an idea for the style guide by LambdaWolf · 2012-02-12 15:05 · Score: 4, Informative

How about, when naming variables, you have to put the first letter of the typename in the start of the variable name!
Hungarian notation isn't about using the typename at all.
Indeed. Here is some good reading on the actual purpose of Hungarian notation, although of course it's used wrong far more often than not. I've never used it myself, correctly or otherwise, but I acknowledge that the original intent was at least sensible.

--
"This algorithm runs in constant time. Come on, 2,147,483,648 is a constant..."
Re:I have an idea for the style guide by SplashMyBandit · 2012-02-12 15:13 · Score: 2, Informative

That may be a good reason. The real reason for the rise of Hungarian Notation is that the Microsoft C compiler didn't do type checking for some time after other C compilers had it. If you wanted to have a clue what type you were using you adopted Charles Simonyi's notation (which was used by FORTRAN devs at the time). The problem is, that awful practice of using 'warts' as a prefix stuck around. It even lingers in C# where interfaces are traditionally prefixed with "I". Fortunately this is something that Java conventions avoid - and if you decide to change an interface into a concrete class during development you don't have to go around and rename everything (plus, such prefixes are unnecessary in the modern age, the compiler helps you when you mistake an interface for a concrete class, so the 'wart' has no upside while having the refactoring downside).
Re:I have an idea for the style guide by cavreader · 2012-02-12 16:35 · Score: 2

Using "I" and the other naming conventions enforced in C# is a good way to provide consistency on multi-developer projects. Variable and class names should be consistent so any follow-up developers can get up to speed faster. With more companies using short term contractors these days is a very useful. I don't advocate any particular naming convention but whatever you use should be consistent. Variable names, class names, method names, and name spaces are just a few ways you can organize the code base and make it easier on the developers.
Re:I have an idea for the style guide by SplashMyBandit · 2012-02-12 17:22 · Score: 2

This is an old-style way of looking at it. I also used to think they would be helpful but now consider them obscuring, you are still thinking in the solution domain rather than trying to get to the problem domain (so that the code reads more like natural language). These days your IDE can tell you the type without you having to pollute your code with these 'warts'. This is why many languages have moved away from such styles. The reason C# has it is that the developers are unable to shake the legacy modes of thought. It turns out that rather than use these artificial constructs to make it easier for following developers it is generally better to aim to make your language simpler. For example, Java is often panned by .NET developers for not having certain constructs but it is a deliberate decision by the Java architects to *keep* the language simple. As a result there are far fewer deprecated constructs and styles in the language. This has a far greater impact on improving code readability for people joining or maintaining a project than using kinda crufty old-style constructs to do this. But yes, I agree with you that consistency is important.
Re:I have an idea for the style guide by swillden · 2012-02-12 18:02 · Score: 3, Informative

The real reason for the rise of Hungarian Notation is that the Microsoft C compiler didn't do type checking for some time after other C compilers had it. If you wanted to have a clue what type you were using you adopted Charles Simonyi's notation (which was used by FORTRAN devs at the time).
Cite? The early Microsoft C compiler was Lattice C, which was an ANSI C compiler. It had to have typechecking.
Also, everything I read says Simonyi invented his notation, or at least the rudiments of it, in the 70s while working for Xerox PARC. So it couldn't have been a reaction to a deficient MS compiler that didn't yet exist.

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Re:I have an idea for the style guide by Coriolis · 2012-02-12 19:14 · Score: 3, Interesting

As a huge fan of fluent code, but also as someone who prefers to see the distinction between a promise and a concrete implementation to be at a glance of the class definition, I have to disagree. Of course you should be using a language derived from your problem domain, but if your problem domain contained all you needed for the solution, then it itself would be the computer program. At some level, you have to use the language of the solution domain, you can't wish it away. I would also say that, these days, having to chance the name from ISomething to plain Something is no big deal, due to built-in refactoring support. Finally, what are the deprecated constructs and styles in C#? Can't think of any of the top of my head.

--
Rgasuya aata! : I have been coding Perl and cannot tell where my fingers are now!
Re:I have an idea for the style guide by mbkennel · 2012-02-12 19:55 · Score: 2

Style guide to Microsoft: don't use words in a way such the lexical representation of "type", commonly called its name, means something entirely different from "typename".
Re:I have an idea for the style guide by DrXym · 2012-02-12 21:41 · Score: 3, Insightful

Microsoft used hungarian notation most likely because it seemed like a good idea at the time. Various BASIC dialects were untyped or only loosely typed ($, % etc.) and C/C++ development environments weren't (and still aren't) very good at reflection / refactoring. So it was a useful hint to the programmer to save them hunting around to find the declaration. Microsoft's book series, e.g. Code Complete also pushed the idea onto external developers.
Nowadays I think the reasons for hungarian have largely disappeared. Modern IDEs for Java or .NET provide enough assistance that you can find out the type of something by hovering over it. You'll get the type and any documentation. And ctrl clicking the type takes you to the definition. There is no need to decorate the type because it just adds noise. Personally I don't even like scoping which some Java devs seem to do with _ on the front of member variables because it usually confuses the IDE.
It may still have some use in JavaScript or Perl or other polymorphic environments where the editor / IDE and the runtime is pretty useless at assisting developers though it should probably be done in a limited way, e.g. s for string, n for number, a for array etc.
Re:I have an idea for the style guide by TheRaven64 · 2012-02-12 23:53 · Score: 5, Informative

The third explanation in this thread, and not the correct one either.
Originally, Hungarian notation was used by the Apps group in Microsoft. It was used to indicate things that were not expressed in the C type system. For example, an integer referring to a column number in a spreadsheet would be colsFoo, while another referring to a row would be rowsFoo. If you wrote something like if (rowCurrent When the Systems group adopted the convention, they started using it for the variable type, not its meaning. This completely defeated the point, but the Systems group version was the one that caught on due to their greater influence within the company.
C is one of the few Algol-family languages where this is actually necessary. In most others, you can create a columns type and a rows type that are both integers but can not be implicitly cast to the other.

--
I am TheRaven on Soylent News
Re:I have an idea for the style guide by TuringTest · 2012-02-13 00:17 · Score: 2

-1 Troll.
As long as you are creating software artifacts that can execute automated behavior, you are programming. You may not be using a general purpose programming language, but it's giving instructions to a computer nevertheless.

--
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Re:I have an idea for the style guide by hey! · 2012-02-13 05:28 · Score: 2

Well, I think the problems with how people used HN are much more complicated than Hungarian Notation == Bad. They have to do with an inappropriate style of HN being adopted by C programmers for historical reasons.
Pointers are something the vast majority of non-C programmers never deal with these days. In the days of 16 bit Intel compatible software the most efficient pointer was a 16 bit integer(ish) value. Such a pointer could only address a 64K space, and so the programmer had to keep straight which pointers where "NEAR" pointers like these, which were 20 bit "FAR" pointers that could address half-again more than the 640K of RAM nobody would ever need, and "HUGE" pointers which could address the same address space as "FAR", but were *normalized so that you could do pointer arithmetic on them*. Clearly having a distinctive naming convention for FAR and HUGE pointers made a lot of sense, because you had to keep track of that to use the variable correctly.
Now set this stuff aside for a second and consider a programmer working in a much higher level language that abstracts all that implementation detail. Suppose he's working on a geographic information systems program where a city's geography is sometimes represented by a point (as it would in a nation-wide map), a polygon (as it would in a metro region map), and a polygon with topological information about its neighbors (as might be used in some sophisticated GIS analysis). If he chose a convention whereby the variables of each type were named "ptCity", "polyCity", and "topoCity", it wouldn't strike us as unreasonable. But if he chose the variable names "shpPtCity", "shpPolyCity", and "covPolyCity" to represent that the first two values come from a shapefile and the third comes from a coverage file (a format with topology), we'd probably say it's *stupid*. Unless this were something like a module that generated shapefiles from coverages, there'd be no reason to burden the maintainer with that detail, or to restrict the semantics of the data.
In this example, the stupid and sensible variable naming conventions are just different styles of "Hungarian Notation".
When you program "close to the iron", say writing device drivers, the *semantics* of a variable and the way it is stored and manipulated by the CPU are one and the same thing. But in the days of segmented memory in Windows those machine oriented details bled through into application programming. So programmers adopted the low-level HN style across the board, which was just dumb, instead of for just pointers, which was sensible. An OS or driver programmer might do some kinds of type casts, say from a pointer to byte array to a pointer to integer array, where remembering the exact type of the variable might remind him to deal with memory alignment and byte-order issues. If an app programmer does something like that you should send him back to his cave so he can bang the rocks together a little longer.
As for university CS professors back in the day insisting on a style of HN that simply regurgitates what the compiler already knows about a variable, that goes to show that most CS professors don't know all that much about programming.

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Re:I have an idea for the style guide by SplashMyBandit · 2012-02-13 07:50 · Score: 2

Yes, it is nice to work with interfaces. No, you shouldn't care whether you are dealing with an interface or a concrete class. Hence, prepending "I" to interfaces is a bad idea. For example, the Java equivalent for writing (internationalized) text streams is "Writer", you don't care if it is a "FileWriter", "StringWriter", "OutputStreamWriter" etc. Note that it is called "Writer" (a word that makes perfect sense) and not "IWriter" (made up computer jargon). So my argument was not against using interfaces, it was against naming those interfaces in an artificial, and these days unnecessary, manner.
Re:I have an idea for the style guide by maxwell+demon · 2012-02-13 13:00 · Score: 2

Hmm perhaps breaking with hiding of implementation details but having a way to tell someone that a thing is an interface (abstract base class) not a specific class seems nice.
Yeah, that's what documentation is for. :-)

--
The Tao of math: The numbers you can count are not the real numbers.

Rude words by madprof · 2012-02-12 10:37 · Score: 5, Informative

Obviously they do have to put in the bit about not using words that some might find offensive in case someone, having a bad day, put it in and they had no come back.
It's quite incredible what some developers, at any size of company, will do sometimes.

Re:Rude words by nschubach · 2012-02-12 10:47 · Score: 5, Funny

What if you are actually writing software for a pimp or dog breeding?

--
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Re:Rude words by madprof · 2012-02-12 10:51 · Score: 2

Then it would be in context and no one would find it offensive.
Oh hang on I'm supposed to come up with a witty reply, not a dull one. :)
Re:Rude words by Samantha+Wright · 2012-02-12 10:53 · Score: 5, Funny

Then you use neutral terminology, like 'executive-level sex worker' and 'that one secretary who talks too much.'

--
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
Re:Rude words by Sulphur · 2012-02-12 12:40 · Score: 2

What if you are actually writing software for a pimp or dog breeding?
Use string variables.

They are bad at naming things. by Anonymous Coward · 2012-02-12 10:41 · Score: 5, Funny

Take the 'Malicious Software Removal Tool' for one example. Sounds to me like a malicious program that goes and removes software from your computer. They should have called it the 'Tool for Removing Malicious Software'. I look at such ambiguity with a laugh. I recently had a dialogue box on my computer saying something along the lines of "Problem Reporting _____". (I forget the exact text.) Does that mean that the system is reporting a problem, or having a problem reporting? Considering that most users of the software are not experts, they should try harder to make things less confusing.

Re:They are bad at naming things. by Anonymous Coward · 2012-02-12 10:56 · Score: 2, Funny

>Take the 'Malicious Software Removal Tool' for one example. Sounds to me like a malicious program that goes and removes software from your computer
Thank you for your bad ass-insight.
Re:They are bad at naming things. by adjuster · 2012-02-12 11:18 · Score: 5, Funny

Reminds me of the short-lived Critical Update Notification Tool Microsoft released back in the early 2000's. (Yeah-- they really named it that, though they _quickly_ backpedaled on the name...)

--
The Attitude Adjuster, I hate me, you can too.
Re:They are bad at naming things. by bsims · 2012-02-12 11:45 · Score: 2

And who can forget Microsoft Services for Unix... with the offical abbriviation of SFU
Re:They are bad at naming things. by 140Mandak262Jamuna · 2012-02-12 12:33 · Score: 4, Funny

Take the 'Malicious Software Removal Tool' for one example. Sounds to me like a malicious program that goes and removes software from your computer.
The name accurately describes what the software does and how. Your explanation that it is a malicious tool that removes software is correct. Your mistake is to assume it is a tool to remove malicious software.

--
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Re:They are bad at naming things. by VortexCortex · 2012-02-12 13:27 · Score: 4, Funny

They should have called it the 'Tool for Removing Malicious Software'
I'm sorry, you'll have to take up your grievance with Richard Stallman; Apparently GPLv3 is the only license allowed for derivatives acronyms such as TRMS.
Re:They are bad at naming things. by Johann+Lau · 2012-02-12 15:53 · Score: 2

Oh I know: "Tool to remove software that is malicious in ways other than those which we have come up with for you today." or in short, TTRSTIMIWOTTWWHCUWFYT.

Bad title by PCM2 · 2012-02-12 10:46 · Score: 5, Informative

I just want to go on record as saying I hate this headline. I didn't pick it. Furthermore, I don't think there's anything in particular about Microsoft developers that makes them "need a style guide" more than anybody else, and that notion had absolutely nothing to do with my column. I just thought it was interesting that a Microsoft style guide exists, that it's available for sale, and that it has some interesting stuff in it about writing for software UIs that a lot of developers probably don't think about. That's about it.

--
Breakfast served all day!

Re:Bad title by davester666 · 2012-02-12 11:01 · Score: 4, Insightful

Why is this for sale? You'd think they would want more well-designed software for their platform, especially with Metro just around the corner.

--
Sleep your way to a whiter smile...date a dentist!
Re:Bad title by gbjbaanb · 2012-02-12 11:18 · Score: 5, Insightful

It's the best way to encourage consistency across applications and the accompanying documentation. Does that not happen anymore?
no, it doesn't happen anymore. The original style guide was good - it said how much space to leave around the edges of dialogs, how big to make buttons and where to put the ok/cancel buttons. the end result was an overall look and feel that made sense no matter which application you used, and that meant TCO was reduced as users knew how to use it.
Fast forward to the XAML/WPF/C# era and all that went out the window in favour of "rich" UIs where you have a stupid coloured orb that everyone thinks is decoration until you realise it's the main system menu, and every application has a different set of awful skins.
I would hope (haven't read it) that this redresses the balance.
Re:Bad title by Altus · 2012-02-12 13:23 · Score: 2

I think the implication here is that you should give away your style guide for free to give every developer access to it, hopefully leading to a more cohesive platform experience.

--
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
Re:Bad title by Gadget_Guy · 2012-02-12 14:56 · Score: 4, Informative

no, it doesn't happen anymore. The original style guide was good...
Which one was the original one? Was it the one for Vista and Windows 7? Or Windows XP? Or this tome for Windows 98, 2000 and XP (which was also available in book format)? And I have this one for Windows 95 on my bookshelf.
I am sure that Windows 3.x had them too. For all the faults of Microsoft, you can't say that they don't like publishing books on how to program their operating systems.

Fast forward to the XAML/WPF/C# era and all that went out the window in favour of "rich" UIs where you have a stupid coloured orb that everyone thinks is decoration until you realise it's the main system menu, and every application has a different set of awful skins.
I agree with you on rise of flashy, non-standard user interfaces, but if you want to adhere to an official style guide now you can still use the ones written for each Windows platform (see my first link).
Re:Bad title by SplashMyBandit · 2012-02-12 15:25 · Score: 3, Interesting

Yeah, the "understated" UIs look great but are actually poorly designed from a usability perspective.
Example: Last week I bought an iPhone 4S and couldn't figure out how to make a call. I went to "Phone" where I had contacts and was presented with buttons for doing Face Time, sending messages, sharing contacts, and adding a contact to favorites, but there was no button to make a call. I mean, given that choosing the Phone app means you will want to make a call on a selected contact about 95% of the time you would think there would be a massive "Call" icon, since that is the most common thing you'd like to do. It turns out you have to tap on the phone number to make the call - even though there is absolutely nothing to indicate that tapping the number would make a call (my expectation was that tapping the number would edit it). Now that I know that all the interface elements are clickable "buttons" *even if they don't look like the buttons shown elsewhere* things are much easier (and this is coming from a long-time user of Macs). While many of the UI features of Apple are excellent I consider their minimalist approach has gone so far as to present too little information. My point here is that while we are decrying Microsoft for their UI designs we can also do the same for Apple. Mostly less is more, but sometimes less really is less. One of my hats is a trained technical writer and from that point-of-view I consider some elements of Apple's style to be very, very bad - but that is not a particularly fashionable point of view at the moment.
Re:Bad title by Froboz23 · 2012-02-12 19:41 · Score: 4, Funny

I agree that this document should be free rather than for sale. For more details on why I think this document should be free, please refer to my Kindle eBook "Why I think the Microsoft Style Guide Should Be Free", available for download from Amazon for only 99 cents.

--
Take off every Sig. For great justice.

Master/slave by Samantha+Wright · 2012-02-12 10:46 · Score: 5, Informative

Similarly, the relationship between USB peripherals could be described as "master/slave," but these terms could also be considered offensive. (The "Microsoft Manual of Style" says such language is prohibited in "at least one U.S. municipality.")

Dear Neil McAllister,

That terminology originally comes from disk drive buses, and the municipality is Los Angeles. Are you really a tech writer?

Sincerely,

Suspicious

--
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!

Re:Master/slave by Samantha+Wright · 2012-02-12 10:49 · Score: 4, Informative

Addendum:

Huh?
Dear Neil McAllister,
Netscape named their implementation of ECMAScript as 'JavaScript' as the result of a cross-promotional stunt with Sun. Netscape was bought by AOL. AOL merged with Time-Warner. This merger was the largest acquisition in business history. I can't believe you don't know this.
Sincerely,
Thinking You Were Born Yesterday, Or Perhaps Last Week At The Earliest

--
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
Re:Master/slave by Samantha+Wright · 2012-02-12 10:50 · Score: 2

Missing context that Slashdot ate:

This howler stuck out, in particular: "JScript is the Microsoft implementation of the ECMAScript scripting language specification, an open standard. Do not refer to it as 'JavaScript,' which is the corresponding implementation by Time Warner." Huh?

--
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
Re:Master/slave by 93+Escort+Wagon · 2012-02-12 11:04 · Score: 4, Informative

Netscape named their implementation of ECMAScript as 'JavaScript' as the result of a cross-promotional stunt with Sun.

Except I seem to recall JavaScript pre-dated ECMAScript - and the ECMAScript Wikpedia page seems to support my recollection of the timing.
The naming was certainly a promotional stunt, though.

--
#DeleteChrome
Re:Master/slave by NoMaster · 2012-02-12 12:42 · Score: 3, Informative

That terminology originally comes from disk drive buses

It's much older than that.

--
What part of "a well regulated militia" do you not understand?
Re:Master/slave by PPH · 2012-02-12 14:40 · Score: 3, Funny

Similarly, the relationship between USB peripherals could be described as "master/slave," but these terms could also be considered offensive. (The "Microsoft Manual of Style" says such language is prohibited in "at least one U.S. municipality.")
Damn! I just finished changing all master/slave references to pimp/bitch. And now they tell me that this won't do either?
How about top/bottom?
Domme/sub?

--
Have gnu, will travel.

You may scoff, but style is everything by phonewebcam · 2012-02-12 10:46 · Score: 4, Funny

Choose the single leg double-hand overarm for distance.
Or, if you want maximum impact, and hence noise when the chair lands, go for height: a full seat grab upper thrust is your best option.
Then there's the full intimidator, often accompanied with shrieks alluding to colorfully burying someone whilst holding it by two legs high above your head - this move requires two full laps of the office before deployment.

If it's in the Style Guide, it actually happened.. by DontScotty · 2012-02-12 10:59 · Score: 4, Interesting

And - people can not avoid or fix mistakes which they do not know about.

Silence on an issue = consent. So, if MSFT had not mentioned avoiding "'pimp' or 'bitch"; someone raised in an environment where that was ok - (looking at you, teens and young twenty-somethings who grew up saying "That's Gay" when you meant wrong, bad, or odd) may not fully realize the problem with borderline and unacceptable language.

Example: Error Message = "What a bitch! Just dumped a debug file in my program folder" or in the HELP>ABOUT saying "Hey, if you want additional functionality, allow me to pimp the ENHANCED version @ paymemorecash.local"

McAllister's an ID10T by Anonymous Coward · 2012-02-12 11:11 · Score: 2, Insightful

'Occasionally, Microsoft's recommendations verge on the absurd. For example, you might not think it necessary to admonish developers to "not use slang that may be considered profane or derogatory, such as 'pimp' or 'bitch,'" but apparently it is.'

Spoken like someone who's never written, read, or worked with any kind of code whatsoever. It's not uncommon for comments to contain language others outside the team will find offensive - developers get comfortable, and start writing for each other instead of the world at large. Since MS releases their code to outside parties, they feel the necessity to remind their coders to remember they're not the only ones reading the source.

Twit.

Design patterns: alternate names by Anonymous Coward · 2012-02-12 11:19 · Score: 5, Funny

You may be familiar with design patterns. Those in the know sometimes give them nonstandard names, such as:

pimp - Define an object that encapsulates how a set of objects interact. Promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
bitch - Attach additional responsibilities to an object dynamically keeping the same interface.
pms - Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
company bathroom - Ensure a class has only one instance, and provide a global point of access to it.
strapon - Convert the interface of a class into another interface clients expect. An adapter lets classes work together that could not otherwise because of incompatible interfaces.
player - Use sharing to support large numbers of similar objects efficiently.
dating - Allows concurrent read access to an object, but requires exclusive access for write operations.
screw - Represent an operation to be performed on the elements of an object structure.
orgy - Combining multiple observers to force properties in different objects to be synchronized or coordinated in some way.
"let's not put it on, baby" - Reduce the overhead of acquiring a lock by first testing the locking criterion (the 'lock hint') in an unsafe manner; only if that succeeds does the actual lock proceed. Can be unsafe when implemented in some language/hardware combinations.
"I love you" - Manages operations that require both a lock to be acquired and a precondition to be satisfied before the operation can be executed.
divorce - Addresses problems with the asynchronous pattern that occur in multithreaded programs
alimony - asynchronous interface to resources that must be handled synchronously.

There is a good reason for this... by wbr1 · 2012-02-12 11:28 · Score: 4, Funny

...admonish developers to "not use slang that may be considered profane or derogatory, such as 'pimp' or 'bitch,'" but apparently it is.'"

Microsoft does not want their true relationship with their customers to become widely known.

--
Silence is a state of mime.

Re:If it's in the Style Guide, it actually happene by bloodhawk · 2012-02-12 11:50 · Score: 3, Interesting

while the derogatory terms etc may seem obvious, there are plenty of less obvious mistakes that people fall into. For instance we used naming conventions on errors in on of our production applications that referred to greek mythology and specifically the underworld. It came as quite a shock when we received official complaints from religious nutcases that said they were offended by our blasphemy. Since then we have had to rewrite a lot of that to use far more boring errors.

No other platform has a style guide? by TheSkepticalOptimist · 2012-02-12 12:03 · Score: 4, Informative

https://developer.apple.com/library/IOs/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html
https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html
http://developer.android.com/design/index.html
http://developer.gnome.org/hig-book/
http://docs.blackberry.com/en/developers/deliverables/36511/index.jsp?name=UI+Guidelines+-+BlackBerry+SmartphonesBlackBerry+Smartphones7.1&language=English&userType=21&category=BlackBerry+UI+Guidelines&subCategory=
http://docs.blackberry.com/en/developers/deliverables/27299/index.jsp?name=UI+Guidelines+-+BlackBerry+PlayBook+TabletBlackBerry+PlayBook+Tablet1.0&language=English&userType=21&category=BlackBerry+UI+Guidelines&subCategory=
http://wiki.eclipse.org/User_Interface_Guidelines ...

Yeah, its hilarious an unusual that Microsoft publishes a design guide for their OS because obviously the author didn't spend 5 minutes on Google...

--
I haven't thought of anything clever to put here, but then again most of you haven't either.

Re:If it's in the Style Guide, it actually happene by DontScotty · 2012-02-12 12:36 · Score: 2

It's not MY political correctness police.

These have become social norms. Norms, that you are FREE to violate. However, violation may come at a cost.

If you are self-employed, you may lose customers.
If you are an employee, you may lose your employment.

I've LOST positions due to language issues/barriers. I'm pretty sure other people have as well.

Much the same way as "http://hothardware.com/News/Tweet-Your-Way-to-Losing-a-Job-Offer/"

It's simple really... 2 rules, 2 things to avoid. by gestalt_n_pepper · 2012-02-12 13:57 · Score: 4, Insightful

1) Software is a conversation. Be polite.

2) Software is a servant, not an equal or a master. Software is the waiter. Don't put behavior in your software that you wouldn't accept in a restaurant.

The most aggravating and common user interface fails to avoid are:

1) Interruptions (e.g. Microsoft dialogs telling you updates have been installed, as if you give a rat's ass, refreshing a window or dialog that doesn't appear to need to be refreshed, being too helpful and hovering like Clippy).

2) Being ignored (Clicking or typing on screen and watching nothing happen).

There are, of course, many other transgressions, but most of them can be addressed by thinking through a restaurant example. If the waiter came and rearranged your dishes and silverware in the middle of your meal, you'd be furious. If the OS comes in and rearranges your screen while you're working, taking away your focus, you'll be furious. If the waiter keeps ignoring you or is slow, you get angry. If the OS keeps ignoring you, or gets slow, you get angry.

There are thousands of things you can do to improve an interface, but miss this stuff and you fail.

--
Please do not read this sig. Thank you.

Re:If it's in the Style Guide, it actually happene by smellotron · 2012-02-12 14:10 · Score: 2

(looking at you, teens and young twenty-somethings who grew up saying "That's Gay" when you meant wrong, bad, or odd)

Hey, that's me! I kicked the habit cold-turkey when a gay coworker hired on. I still occasionally have trouble with "retarded", and South Park certainly doesn't make it easier.

Re:If it's in the Style Guide, it actually happene by russotto · 2012-02-12 14:40 · Score: 3, Interesting

while the derogatory terms etc may seem obvious, there are plenty of less obvious mistakes that people fall into.

And sometimes not-mistakes. As some of the executives of a company I once worked for had to explain away (to a female user working for a major customer, naturally) an error box written by an ex-employee by claiming it was simply an unfortunate typo for "count error".

Re:Shorter version by Gadget_Guy · 2012-02-12 15:17 · Score: 2, Interesting

Why MS devs need a style guide: they thought the ribbon was a good idea.

Quite frankly, it was. I did have some problems, like the icon that turned out to be a menu (how many people had problems with that?) and Microsoft's refusal to repeat any function on two different tabs (so if something is on the home tab then it cannot appear elsewhere even if it should logically be on that other tab). However, if you watch ordinary people using Office 2003 (or below) then you will notice that they tend to hunt around the toolbars for functions rather than use the menus where you don't need to hover the mouse to read what a button does. The ribbon is perfect for those people. It is also good for tablet users.

The biggest problem people had with the ribbon was that it changed an existing user interface that had not changed substantially since the Windows 3.1 days. All of a sudden, they had to re-learn the package again. That is a pain in the proverbials. However, new users to Office 2007 and 2010 must surely be scratching their heads and wondering what all the fuss was about.

Ob. scenario: by Tastecicles · 2012-02-12 16:47 · Score: 2, Funny

Clippy: "It looks like you're trying to pimp your presentation. Would you like some help with this?"

Options: "Yes. Show me how to pimp my document!"
"No, fuck off you annoying little shit!"
"If I have to turn you off in the options again I'm gonna bitchslap my laptop!"

--
Operation Guillotine is in effect.

Re:It's simple really... 2 rules, 2 things to avoi by Chrisq · 2012-02-12 21:35 · Score: 2

2) Software is a servant, not an equal or a master.

Can we talk about this, Dave?

Re:Nobody is happy by TheRaven64 · 2012-02-12 23:45 · Score: 4, Funny

is that an API does not break "unwritten" conventions like always returning true even when the operation was unsuccessful

Most POSIX APIs return true on error and false on failure. The idea is that this lets you write if (something()) { error_handler(); }. I've no idea why they thought this made more sense than if (!something()), but judging by the rest of UNIX I suspect that they had to type their code in morse with one hand while fighting a tiger with the other, so every character saved could mean the difference between life and death...

--
I am TheRaven on Soylent News

Art of programming by jellomizer · 2012-02-12 23:53 · Score: 4, Insightful

Software development is a form of art where Math/Logic/Science/Engineering are our mediums to work with. Being an art form the software developer feels the need to express themselves in their program, in one way or an other.
However much like real artists in order to make a living they need to do a buch of commissioned work where you need to make what the boss wants and your personal style is limited. And as you get more artists on a project you need a style guide to make sure the project is consistent.
GNU projects often lose a good UI compared to their closed source counterpart because each artist is making their own statement in the program. I find that the GIMP does this. Now this isn't a flaw in the GNU but a good GNU project needs the same oversite and rules a good closed source solution needs, and often much earlier in the process because open source you get a lot of people doing a little bit of code, while closed source you get a few people doing the bulk.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.

Mozilla Firefox "Well, this is embarassing." by Blaskowicz · 2012-02-13 01:06 · Score: 2

I remember being infuriated by this message, it's meaningless and too casual. It doesn't provide any information as to the cause of the error nor does say "unkown error". It makes me wonder whom is it embarassing for. Me? Mozilla? Firefox itself? Does it mean "we're sorry for you using such crappy software"?

I wonder about how this message is perceived in company/corporate settings. It's an exemple of bad writing style to me. You've crashed, don't try to be familiar or funny about it.

Re:Nobody is happy by 19thNervousBreakdown · 2012-02-13 02:11 · Score: 5, Insightful

Because that way there's only one success, and many failures.

0(false) = success 1(true) = failure 2(true) = different failure 3(true) = yet another failure

--
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>

Re:Nobody is happy by UnknownSoldier · 2012-02-13 05:16 · Score: 3, Informative

> Most POSIX APIs return true on error and false on success.

You were being funny but it comes down to granularity.

* For success you only need to know that it passed.
* If the function fails you want more details.

Here is an example:

enum Result { PASS , FAIL_OUT_OF_MEMORY , FAIL_INVALID_HANDLE , FAIL_BAD_PATH }; Result ReadFile( const char * filename, void * buffer ); void Foo( const char * filename, void * buffer ) { Result result; if (result = ReadFile( filename, buffer )) { /* handle error */ }

Make sense?

Slashdot Mirror

Why Microsoft Developers Need a Style Guide

69 of 262 comments (clear)