Found this in minwindef.h:
typedef WORD ATOM; //BUGBUG - might want to remove this from minwin
I know what an ATOM is ... but what is up with "BUGBUG?" This is in the 8.1 SDK, specifically:
\Program Files (x86)\Windows Kits\8.1\Include\shared\minwindef.h
It's just a tag used to mark things that should be investigated in the future.
"BUG" is too ambiguous: you might use the word "bug" for all sorts of things when writing comments or code. But it's unlikely that you're going to use "bugbug" (no spaces) anywhere, so by convention some development teams use it to track bugs or (as is the case here) things that should be investigated later. This way the team can easily grep for "BUGBUG" and find all of the marked lines of code.
Perhaps it's a suggestion that ATOM should be moved into winuser.h rather than its current location.
Related
I have a large codebase that uses Systems Hungarian for most variable names, which basically means I have lots of objQueue's, objCommon's, dtDataSet's et cetera.
Is there any way to convert most of them? Especially, I want to get rid of irritating obj ones that have absolutely no sense, make variable names seem similar and the code completely unreadable.
There was a similar question but it was asking whether it's worth to do the replace.
Answers like “leave it as is” are not of any use to me because I'm definitely sure I need to do this.
The codebase is really large, and I don't want to rename variables one by one. Neither do I want to run Find & Replace because I'll get false hits and mess up code even further.
Is there any automated tool to make such replacements in Visual Studio? Some addin for Resharper, whatever?
Alas, but it seems like there is no bulk rename tool for C#.
Please correct me if I am wrong.
One solution would be to use something like Visual Assist's rename feature.
Other than that, a very careful search'n'replace (with a build between each modification followed by a check-in into source-control).
I've been looking into the NoStepInto feature of Visual Studio.
Andy Pennell's post How to Not Step Into Functions using the Visual C++ Debugger has been extremely helpful.
But as far as I can tell, in VS2008 the string name of the rule no longer has to be an integer, and no longer has any effect on the priority of the rule.
I have played around with the registry a bit and it seems to use the best match or maximal match (not sure what the correct expression is).
So if I have the following two rules
boost boost\:\:.*=NoStepInto
boost::shared_ptr boost\:\:shared_ptr.*=StepInto
it does step into shared pointers, which I assume is because the second rule is a more exact match.
Has anyone come across any information on anywhere confirming or refuting this? I can't seem to find any.
Thank you!
I just tested this and things seem to work the way I expect them to:
20 boost\:\:.*=NoStepInto
30 boost\:\:shared_ptr.*=StepInto
Does not step me into any boost namespace functions, except for shared_ptr's.
Changing the priorities around to
10 boost\:\:shared_ptr.*=StepInto
20 boost\:\:.*=NoStepInto
Does not step me into any boost namespace functions at all.
Let me pose a bit of background information before asking my question:
I recently joined a new software development group that uses Rational tools for configuration management, including a source control and change management system.
In addition to these tools, the team has a standard practice of noting any code changes as a comment in the code, such as:
///<history>
[mt] 3/15/2009 Made abc changes to fix xyz
///</history>
Their official purpose for the commenting standard is that "the comments provide traceability from requirement to code modification".
I am preparing to pose an argument that this practice is unnecessary and redundant; that the team should get rid of this standard immediately.
To wit - the change management system is the place to build traceability from requirement to code modification, and source control can provide detailed history of changes by performing a Diff between versions. When source code is checked in, the corresponding change management ticket is noted. When a CM ticket is resolved, we note which source code files were modified. I believe this provides a sufficient cross-reference for the desired traceability.
I would like to know if anyone disagrees with my argument. Am I missing some benefit of commented source code history that change management and source control systems cannot provide?
For myself, I have always found such comments to be more trouble than they're worth: they can cause merge conflicts, can appear as 'false positives' when you're trying to isolate the diffs between two versions, and may reference code changes that have since been obsoleted by later changes.
It's often (not always, but often) possible to change version-control systems without losing metadata. If you were to move your code to a system that doesn't support this, it would not be hard to write a script to convert the change history into comments before the cutover.
A comment allows you to find all the changes and their reasons in the code right where they are relevant without having to dig into diffs and version control system intricacies. Furthermore, should you decide to change of version control system, the comments will stay.
I worked on a large project with similar practice that had changed of source control system twice. There wasn't a day when I wasn't glad to have these comments.
Is it redundant? Yes.
Is it unnecessary? No.
I've always thought that code should be, of course, under version control, and that the current source code (the one that you can open and read today) should be valid only in present tense.
It doesn't matter if a report could have up to 3 axis in the past and last month you updated it to support up to 6 axis. It doesn't matter if you expanded some function or fixed some bug, as long as the current version can be easily understood. When you fix a bug, just leave the fixed code.
There's an exception, though. If (and only if) the fixed code looks less intuitive to you than the previous, incorrect one; if you feel that someone might come tomorrow and, just by reading the code, be tempted to change it back to what "seems more correct", then it's good to add a comment: "This is done this way to avoid... blah blah blah." Also, if the problem behind is an infamous war story inside the team's culture, or if for some reason the bug report database contains very interesting information about this part of the code, I wouldn't find it incorrect to add "(see Bug Id 10005)" to the explaining comment.
The one that jumps to mind to me is vendor lockin. If you ever moved away from Rational, you'd need to make sure that the full change history was maintained during the migration - not just the version of the artifacts.
When you're in the code you need to know why it's structured like that, hence in code commenting. Tools that sit outside the code, good though they may be, require far too much of a context shift in your brain to be useful. As well as that, trying to reverse engineer the code intent from documentation and a diff is pretty damn hard, I'd much rather read a line of comment any day.
There was a phase in the code I work on, back in the 1994-96 time frame, where there was a tendency to insert change history comments at the top of the file. Those comments are now meaningless and useless, and one of the many standard cleanups I perform when editing files containing such comments is to remove them.
In contrast, there are also some comments with a bug number at the location where the change is made, typically explaining why the ridiculous code is as it is. These can be very helpful. The bug number gives you somewhere else to look for information, and fingers the culprit (or victim - it varies).
On the other hand, items like this one - genuine; cleaned up last week - make me grit my teeth.
if (ctab->tarray && ctab->tarray[i])
#ifndef NT
prt_theargs(*(ctab->tarray[i]));
#else
/* Correct the parameter type mismatch in the line above */
prt_theargs(ctab->tarray[i]);
#endif /* NT */
The NT team got the call correct; why they thought it was a platform-specific fix is beyond me. Of course, if the code had used prototypes instead of just parameterless declarations before now, then the Unix team would have had to fix the code too. The comment was a help - assuring me that the bug was genuine - but exasperating.
Are there any practices regarding using codenames of products in Visual Studio projects and solutions? In that typically, namespaces, assembly names, binary outputs, et al need to be renamed once a product name is chosen: is there any way to deal with this?
In one place I worked we'd choose an unrelated and inoffensive, and typically systematic name for any given project.. Jupiter, Orca, Feynman whatever... and stick with that namespace forevermore.
Because as you've seen what the marketing/client/board chooses to call a product (hell, even what version number they choose) is so rarely going to be known at the start let alone the same by the end, that it's just so much easier for everyone to be able to have a fixed internal reference they don't have to refactor later.
I can't stress how important it is that the name is simple, one word and inoffensive though.
This will partly depend on the type of product. If it's a client library - or anything that will require users to see the names - then clearly the names matter. I don't think it really matters otherwise. Bear in mind that different versions of the product may have new codenames (e.g. Everett, Whidbey, Orcas for Visual Studio) - you don't want to have to rename the code each time you start a new version!
I have this:
SolutionName: Foo.sln
Assembly:
Foo.Bar
Namespaces are:
Foo.Bar.Views
Foo.Bar.Model
Foo.Bar.BusinessObjects
Foo.Bar.Services
Should the directory structure be like this?
__Foo/Foo.Bar/Foo.Bar.View__ or __Foo/Bar/View__
If you keep the Visual Studio option of "Automatic Namespaces" you would need to have Foo/Bar/Views. Since this is the default behavior of Visual Studio people will be most used to this. Plus it keeps your folder names/paths from getting excessively long.
This is entirely personal preference. I would choose the latter.
Ask yourself the question, "Am I adding any useful information by repeating Foo and Bar in the sub-folders?" The answer here, in my opinion, is no, simply because the information is redundant. You've also created yourself a maintenance problem; if you need to rename Bar you now have to rename Foo.Bar, Foo.Bar.View, Foo.Bar.Model ...
Well, it can be anything you wish. Either are valid, but the former might get a little redundant and lead to directory hierarchies which are a little hard on the eyes/prohibitive.
Foo/Bar/View seems to be natural. Also MSVS tends to map solution folders to namespaces (i.e. if you add Abc folder to your solution each class you add to this folder will be in root_namespace.Abc namespace)
Foo/Bar/View seems a better choice, more if individual files are named as the individual types (e.g. Foo.Bar.View.IView => Foo/Bar/View/IView.cs).
That's a great pattern to follow, which makes it easier to find types, scripting over sources, do some metrics, etc.