I think that's nice, but utterly misses the point. Why am I a programmer today? Because, back in the day, I owned a cool machine that everybody else owned and I wanted to explore it. Why would I want to own a piece of junk that nobody else has? Even if I build something great on it, noone will ever know!
Stick a keyboard and a halfway decent programming language on a PS3 or a 360 or a Wii (it doesn't matter which), and see the programming literacy soar upwards.
Oh, and with halfway decent I don't mean "some glorified scripting language". I mean something that gives direct access to the hardware, no matter how hard that may be to program for. That's where we all cut our teeth, that's where you can build some real skills. The goal is not to allow *everyone* to work with it, but rather to allow the smart kids to do stuff that noone else can.
But seriously, when did Fahrenheit stop working? He passed away in 1736. It is likely that he stopped working some time before that point, although we cannot be sure that he didn't die at his desk.
I never got the (recent?) craze over using the latest SCM of the week myself. Dude, SVN is ***EIGHT YEARS*** old. It is hardly the craze of the week.
If one system works good enough for you right now, why switch? True. But what if it sucks, why keep telling yourself that it is really great? Because that's the problem with CVS: it really isn't all that great.
I mean, OpenBSD has stated in the past that CVS works well enough for them, and the risk of converting the repository is not worth it just for some newer system. In fact, it's partially behind the motivation to develop OpenCVS.... Oh well, if *Theo* said that then it is ok...
I can't agree with the idea of making code boring. Boring code makes the reader careless. Fine, the chances of me employing you were slim to start with so it isn't a great loss for either one of us;-)
And, if it can, it should be exciting in how well it expresses the problem. I guess you are a few years younger than I am. I used to think like that. After enough years in the corporate grinder, you are just happy when you find some lucid, boring, non-special piece of code that just does what it is supposed to do in the simplest way possible. Because let's face it, I (and I guess everyone else) gets to see lots of exciting, dare-devil, unusual code and it always sucks having to understand, maintain, or change it.
If you can get your hands on the source code for the very early Unix OS versions (v5, v6) and Dennis Ritchie's C compiler, I suggest you do them. There is much to criticize, but far more to revel in; this is exciting code in the amount it accomplishes with relatively few lines; if you are still malleable it may change your code permanently--for the better. Wasn't I just arguing for precisely that? Doing what is needed in the most simple, most lucid way possible?
Teach a man to fish, and he'll feed himself for years.
Hackers follow this model when giving support. Even if the asker gave such details, we'd likely show them how to figure out the answer themselves. That's very nice. But it would be nice if hackers would recognize that, occasionally, just fixing the problem is all that is required, and long theoretical answers that do not help *at all* aren't welcome. It makes them come across as being extremely unhelpful, unpleasant, elitist human beings.
Simple example: many, many years ago, I asked the resident hacker at the university how to do something slightly esoteric under UNIX.
His answer? "man" Nothing else, just that one word.
When I complained that his "teaching" did not help because I didn't know what to look for, he just stared at me and intoned "man man".
That's not helpful. That's not pleasant. That's elitist bullshit, and it is the thing that gives hackers their bad name as social misfits. Quite frankly, that was the point where I decided I didn't care for UNIX, nor for the attitude that pervades its users.
I'm not trying to belittle your problems and I am in no way affiliated with Mozilla or Firefox, but on the dozen of machines I use regularly I have never seen the problem you describe. Even though I regularly have twenty, thirty, or more tabs open at a time, and have lots of extensions installed, and leave FF open for the entire day.
And I haven't seen FF crash. Never. On any of those machines. Apart from your little report, and the link (which conveniently points to another posting by you(!)), I haven't heard of people complaining about it either.
The way you repeat the same accusations (at least) four times in the space of two screens, and offer no proof at all beyond that link to your own message, suggests very strongly that you have an agenda. Your bug report 222660 (yes, I read your text!) doesn't contain any "easily reproducable steps", it actually reads
Reproducible: Always
Steps to Reproduce: 1. 2. 3.
Do you call that a bugreport? No wonder it gets marked as invalid. Similarly, your list of articles fails to convince: some pointers to decreasing the cache size is not proof of a usability-destroying bug in the application.
Also, next time just say "...when I'm browsing porn". We all know what you mean with "performing research" anyway...
I saw your first line in the preview, and immediately thought, 'have you never forgotten to unlock a mutex?'
No, my cMutex class has never yet failed to unlock upon leaving the logical block that contained it. But thank you for your concern;-)
Failure to check return codes or catch exceptions also fall into the same category of missing code that causes failure.
Of course. Removing too much code is just as wrong; if something is checking return codes it is doing that for a reason and must be there. Having said that, I prefer to wrap such functions in something that throws a proper exception. Typically they work on some parameter that is better controlled using RAII anyway so having a class is a natural choice.
And once your code is exception-aware, adding a new source of exceptions somewhere is typically not an issue at all.
Nevertheless, I am in complete agreement with your general principles: from my experience, I have come to consider the prevalence of inordinate and gratuitous complexity as being the least-recognized problem in software design today - though it's really a symptom of a deeper problem, in how developers think about design, for which I have no solution.
I try to approach it as a cost driver: a simpler problem is a cheaper problem. This is something you can do at any level: when bidding, during contract negotiation, during requirement gathering, when drawing up the architecture, etc. In my experience at least, customers generally do appreciate it when I attempt to keep complexity down (of course I give them good reasons for wanting to do so).
I don't believe that code can be truly self-documenting (at least not in C++ and similar languages), and I see that, unlike some other responders to this question, you don't take an absolute position on this.
Generally speaking, any absolute position is going to be wrong at least some of the time. For example, if a goto really is the best way to express something, fine, use one already. The tools in your toolbox are there for a reason, and each has its proper time and place.
In that vein, I spit on any coding standard that forbids the use of exceptions, operator overloading, or templates, to name three of the common culprits. Why not forbid the use of the letters T and G while you are at it?
"Hi mr. carpenter, I want you to renovate my house. But you don't get to use a saw or a drill, because people might get hurt using them."
The problem lies in dealing with interactions between textually and temporally separated aspects of the code: two components whose interaction preserves some invariant; "we need to do this / it's safe to do this because..."; "this is better than {the obvious solution} because...". Design needs to be understood, and to be understood, it needs to be explained where not self-evident
Exactly. And that's where comments have their place: to explain _what_ is going on, and _why_ it is going on. I'm not so much interested in _how_ unless it's been mangled beyond recognition, and in that case I first want to know about _why_ that was necessary anyway. After which I'll probably flag that code for rewriting anyway.
is there a self-documenting C++ implementation of the qwiksort algorithm?
I doubt it. Quicksort is not obvious. But hey, this will go a long way:
void QuickSort (vector &Array)...
Apart from unnecessarily reproducing an STL function, and thereby making it redundant (and thus fall foul of the "cut where possible" rule), it _is_ clear what is going to happen in this function: the variable 'Array' is going to be sorted in ascending order.
If that is not true, no amount of commenting will save you from the maintenance horror that ensues. Changing the name, however, will.
Actually I have another little rule that I find helps my code considerably: don't use negative names. What do you find mor
Any of line code that is written can fail; any line of code that is not written will never need to be debugged, documented, examined, nor will it ever crash.
Based on that principle, the ideal program consists of the minimum number of lines of code that leads to the desired result. In many situations you will find that you cannot get away with having zero lines of code; in the lines that _are_ necessary, strive for maximum clarity above all else. Always ruthlessly cut everything that does not need to be there.
Try to make the code as boring as you possibly can; always strive to use the same patterns for everything where possible and appropriate. Seeing an alternative implementation then automatically becomes a flag, warning about potential mistakes and unusual circumstances.
_Do not_ maximize comment density. Whenever you _should_ write a comment, consider if you can use variable or function naming to achieve the same effect.
Don't use variables; only use constants (i.e. prefix declarations where possible with 'const'). Minimize their scope. You will find that only a very small number of the things that you think of as "variables" today are in fact variable.
Make your code checkable by the compiler as much as you can. This is not the same as turning on all warnings, and then peppering the code with workarounds for nonsensical warnings. It is ok to turn off silly warnings, such as 4800, 4100, or 4786 in Visual C++.
I could write another ten pages, but this should get you started. For the record, my credentials mostly include C++ software used to control and test spacecraft. Software failures can in principle lead to "loss of item under test", with associated astronomical price tag. So I have some appreciation for good code.
Can you give us some idea about the nature of the project: was it cutting edge technology or something that is generally assumed to be clearly understood? What total size (roughly) are we looking at here?
What were the factors that, in your opinion, contributed most to the codebase becoming so unworkable? What best practices were being followed, but failed to help? And which ones were not followed but might have helped?
You clearly name "Bob" as the guilty party for many problems, but are there other factors apart from incompetent management? (bad code generally speaking doesn't write itself...)
I'm not sure why there is all this outrage over such actions by Sweden, since the US has stated years ago that it considers *any* internet communication that touches a US-controlled machine in any way to be in its jurisdiction... Which, in todays' world, is virtually the same as claiming global jurisdiction over all communication.
Or is it only a problem if *other* governments are doing it, instead of your own?
Email has evolved. Our connectivity has evolved (remember the days of 110 "baud" modems?). To say that email should be restricted to 20 year old technology (maybe even including the speed of transmission?) at the expense of effective communications makes as much sense as saying that manuals should still be restricted to printed copies from line printer output (in monospaced font!) -- and that updates should be done via regularly distributed change pages).
I gather it you don't get many multi-megabyte power point slides containing 2 line jokes from newbie morons. I gather you still use a 110 baud modem, given that a simple quotation character was already too much effort...
What about it? The theory only states that programs exist for which halting cannot be determined. That is not the same as saying that halting cannot be determined for every last single program, which is usually how uninformed undergraduates tend to understand it. Just to give two quick examples:
10 rem this will never halt 20 goto 20
Or this one:
10 rem this will always halt
There are two interesting things here: first, I'd bet that for 99.9% of all programs in real life, it is not only possible to determine if it will halt or not, but it is in fact trivial.
And second, thank you for proving my point that people frequently misunderstand the implications of any given theory.
People don't like doing low level, thankless, GUI stuff. They like making interfaces, not improving the speed of existing widgets. It would be difficult to get a sufficient number of people to work on the project reliably, IMHO. Are you seriously making the point that open source developers like making interfaces? How in the name of all that is holy do you then explain the aweful mess of crappy interfaces that plagues the open source world, may I ask? That's not a labor of love, that's the work of the DEVIL! The DEVIL, I tell you! (;-) )
(which is not to say that there aren't any good projects, but the ones with crappy interfaces and lacking documentation are certainly in the majority...)
That's because people routinely misunderstand theory.
For example: "it is impossible to write a program that can determine if another program will halt or not" is often reworded as "it is impossible to determine if a specific, given program will halt or not", which is patently untrue.
The theory in this case appears to be, if I understand correctly: "it is impossible to make a complete copy of a message without it being detected." So they just figured they can make a partial copy, thereby side-stepping detection, but still getting a lot of information.
The theory is right; the implications of that theory (that therefore all communication using it must be secure) is not.
Here in the Netherlands (which, contrary to popular belief, is not a nation of potheads and perverts) we had the local equivalent of a district attorney who threw out his old computer - containing child porn. The computer was found and the content were made public.
The result? He was spoken to in a firm tone of voice, and was moved to a cushy job far from the public eye. THAT'S ALL. He was not fired. He was not prosecuted.
The reasoning behind this? Well, he had apparently not intended to download child porn, he was just downloading normal porn (which is perfectly legal) and had accidentally included child porn as well.
Now, let's see a normal citizen try that particular defense...
So if someone important, like a DA, is revealed on national TV to have downloaded child porn, it will just be swept under the rug. End of story.
Of course, maybe things are different in the US. If you believe that I want you to hear about this great bridge I'm selling...
If a home user wants to use a particular proprietary program, but the publisher won't sell the user a lawfully made copy of the program at any price, what should the user do? In that particular situation, fine, copy it. If they don't want to take your money, they shouldn't complain.
How about a company willing to sell, at a reasonable price, just to recoup the massive cost needed to build the software in the first place? Just saying that replication and distribution costs are close to zero is only counting a very small part of the total cost.
Delivering a Ferrari to my door can be done for a few euro's (the cost of the gas for the trip from the garage to my house). Yet instinctively, most of us would realize that this is not going to happen unless I also pay for the design, production, marketing, and overal status of owning such a car.
Did they release the drivers for all the onboard hardware, though? What if we want to build our own Mars lander and mod the digger a bit, or use a different landing sequence?
What would you have it do to determine why it is no longer getting critical data? Send out a droid to check the cat5 cables? Its a frikin computer in a rack, not R2D2. Oh, I'm so going to use that one during a meeting...
Hello, let's have some perspective here. There are plenty of people who would rejoice if 700MB downloads of free operating systems were no longer possible. Those people have billions in the bank and enough political influence to make this happen.
So don't say that this is a bad side effect. I see it very much as an INTENDED side effect.
...and pegging the other PowerPC processor handling the framebuffer...
...The 2 main PPEs are unimpressive - they're fast, but have blocks removed that make the PowerPC G5 cores slower than they should be... Wait, does the PS3 have two main processing cores? Or are you counting the same core twice: once inside the VM, and once outside?
TECHNICALLY, the "fax machine" was invented in the 19th century. It became WIDELY used in the 1970s. While the first EMAIL may have been keyed in 1965, it could HARDLY have been considered to have been in WIDE use.
So, YES, the fax machine is OLDER. Much older. And we all sincerely apologize for getting on your lawn!
I use that ten years old IDE because it is more pleasant to work with than the more recent versions.
Something really simple that *really* annoys the hell out of me in any later version: in VS6, you can cancel the message window (i.e. make it disappear) by hitting escape. In later versions, you cannot.
In VS6 you can create keyboard macro's and bind them to any key you want. I've been looking for this option in later versions and could not find it.
In VS6, DevStudio was first and foremost a C++ environment with some other stuff thrown in. In later versions it is the other way around: the normal C++ stuff seems to be an afterthought, and the focus is on lots of other stuff I don't use and don't care about, like HTML and.NET.
The list was longer, but it has been a while since I last used those later versions.
Oh, and those "free" versions of yours? They aren't free for corporate use...
Slashdot Mirror
I think that's nice, but utterly misses the point. Why am I a programmer today? Because, back in the day, I owned a cool machine that everybody else owned and I wanted to explore it. Why would I want to own a piece of junk that nobody else has? Even if I build something great on it, noone will ever know!
Stick a keyboard and a halfway decent programming language on a PS3 or a 360 or a Wii (it doesn't matter which), and see the programming literacy soar upwards.
Oh, and with halfway decent I don't mean "some glorified scripting language". I mean something that gives direct access to the hardware, no matter how hard that may be to program for. That's where we all cut our teeth, that's where you can build some real skills. The goal is not to allow *everyone* to work with it, but rather to allow the smart kids to do stuff that noone else can.
Teach a man to fish, and he'll feed himself for years.
Hackers follow this model when giving support. Even if the asker gave such details, we'd likely show them how to figure out the answer themselves. That's very nice. But it would be nice if hackers would recognize that, occasionally, just fixing the problem is all that is required, and long theoretical answers that do not help *at all* aren't welcome. It makes them come across as being extremely unhelpful, unpleasant, elitist human beings.
Simple example: many, many years ago, I asked the resident hacker at the university how to do something slightly esoteric under UNIX.
His answer? "man" Nothing else, just that one word.
When I complained that his "teaching" did not help because I didn't know what to look for, he just stared at me and intoned "man man".
That's not helpful. That's not pleasant. That's elitist bullshit, and it is the thing that gives hackers their bad name as social misfits. Quite frankly, that was the point where I decided I didn't care for UNIX, nor for the attitude that pervades its users.
I'm not trying to belittle your problems and I am in no way affiliated with Mozilla or Firefox, but on the dozen of machines I use regularly I have never seen the problem you describe. Even though I regularly have twenty, thirty, or more tabs open at a time, and have lots of extensions installed, and leave FF open for the entire day.
And I haven't seen FF crash. Never. On any of those machines. Apart from your little report, and the link (which conveniently points to another posting by you(!)), I haven't heard of people complaining about it either.
The way you repeat the same accusations (at least) four times in the space of two screens, and offer no proof at all beyond that link to your own message, suggests very strongly that you have an agenda. Your bug report 222660 (yes, I read your text!) doesn't contain any "easily reproducable steps", it actually reads
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Do you call that a bugreport? No wonder it gets marked as invalid. Similarly, your list of articles fails to convince: some pointers to decreasing the cache size is not proof of a usability-destroying bug in the application.
Also, next time just say "...when I'm browsing porn". We all know what you mean with "performing research" anyway...
I saw your first line in the preview, and immediately thought, 'have you never forgotten to unlock a mutex?'
No, my cMutex class has never yet failed to unlock upon leaving the logical block that contained it. But thank you for your concern ;-)
Failure to check return codes or catch exceptions also fall into the same category of missing code that causes failure.
Of course. Removing too much code is just as wrong; if something is checking return codes it is doing that for a reason and must be there. Having said that, I prefer to wrap such functions in something that throws a proper exception. Typically they work on some parameter that is better controlled using RAII anyway so having a class is a natural choice.
And once your code is exception-aware, adding a new source of exceptions somewhere is typically not an issue at all.
Nevertheless, I am in complete agreement with your general principles: from my experience, I have come to consider the prevalence of inordinate and gratuitous complexity as being the least-recognized problem in software design today - though it's really a symptom of a deeper problem, in how developers think about design, for which I have no solution.
I try to approach it as a cost driver: a simpler problem is a cheaper problem. This is something you can do at any level: when bidding, during contract negotiation, during requirement gathering, when drawing up the architecture, etc. In my experience at least, customers generally do appreciate it when I attempt to keep complexity down (of course I give them good reasons for wanting to do so).
I don't believe that code can be truly self-documenting (at least not in C++ and similar languages), and I see that, unlike some other responders to this question, you don't take an absolute position on this.
Generally speaking, any absolute position is going to be wrong at least some of the time. For example, if a goto really is the best way to express something, fine, use one already. The tools in your toolbox are there for a reason, and each has its proper time and place.
In that vein, I spit on any coding standard that forbids the use of exceptions, operator overloading, or templates, to name three of the common culprits. Why not forbid the use of the letters T and G while you are at it?
"Hi mr. carpenter, I want you to renovate my house. But you don't get to use a saw or a drill, because people might get hurt using them."
The problem lies in dealing with interactions between textually and temporally separated aspects of the code: two components whose interaction preserves some invariant; "we need to do this / it's safe to do this because..."; "this is better than {the obvious solution} because...". Design needs to be understood, and to be understood, it needs to be explained where not self-evident
Exactly. And that's where comments have their place: to explain _what_ is going on, and _why_ it is going on. I'm not so much interested in _how_ unless it's been mangled beyond recognition, and in that case I first want to know about _why_ that was necessary anyway. After which I'll probably flag that code for rewriting anyway.
is there a self-documenting C++ implementation of the qwiksort algorithm?
I doubt it. Quicksort is not obvious. But hey, this will go a long way:
...
void QuickSort (vector &Array)
Apart from unnecessarily reproducing an STL function, and thereby making it redundant (and thus fall foul of the "cut where possible" rule), it _is_ clear what is going to happen in this function: the variable 'Array' is going to be sorted in ascending order.
If that is not true, no amount of commenting will save you from the maintenance horror that ensues. Changing the name, however, will.
Actually I have another little rule that I find helps my code considerably: don't use negative names. What do you find mor
Any of line code that is written can fail; any line of code that is not written will never need to be debugged, documented, examined, nor will it ever crash.
Based on that principle, the ideal program consists of the minimum number of lines of code that leads to the desired result. In many situations you will find that you cannot get away with having zero lines of code; in the lines that _are_ necessary, strive for maximum clarity above all else. Always ruthlessly cut everything that does not need to be there.
Try to make the code as boring as you possibly can; always strive to use the same patterns for everything where possible and appropriate. Seeing an alternative implementation then automatically becomes a flag, warning about potential mistakes and unusual circumstances.
_Do not_ maximize comment density. Whenever you _should_ write a comment, consider if you can use variable or function naming to achieve the same effect.
Don't use variables; only use constants (i.e. prefix declarations where possible with 'const'). Minimize their scope. You will find that only a very small number of the things that you think of as "variables" today are in fact variable.
Make your code checkable by the compiler as much as you can. This is not the same as turning on all warnings, and then peppering the code with workarounds for nonsensical warnings. It is ok to turn off silly warnings, such as 4800, 4100, or 4786 in Visual C++.
I could write another ten pages, but this should get you started. For the record, my credentials mostly include C++ software used to control and test spacecraft. Software failures can in principle lead to "loss of item under test", with associated astronomical price tag. So I have some appreciation for good code.
Can you give us some idea about the nature of the project: was it cutting edge technology or something that is generally assumed to be clearly understood? What total size (roughly) are we looking at here?
What were the factors that, in your opinion, contributed most to the codebase becoming so unworkable? What best practices were being followed, but failed to help? And which ones were not followed but might have helped?
You clearly name "Bob" as the guilty party for many problems, but are there other factors apart from incompetent management? (bad code generally speaking doesn't write itself...)
I'm not sure why there is all this outrage over such actions by Sweden, since the US has stated years ago that it considers *any* internet communication that touches a US-controlled machine in any way to be in its jurisdiction... Which, in todays' world, is virtually the same as claiming global jurisdiction over all communication.
Or is it only a problem if *other* governments are doing it, instead of your own?
I gather it you don't get many multi-megabyte power point slides containing 2 line jokes from newbie morons. I gather you still use a 110 baud modem, given that a simple quotation character was already too much effort...
What about it? The theory only states that programs exist for which halting cannot be determined. That is not the same as saying that halting cannot be determined for every last single program, which is usually how uninformed undergraduates tend to understand it. Just to give two quick examples:
10 rem this will never halt
20 goto 20
Or this one:
10 rem this will always halt
There are two interesting things here: first, I'd bet that for 99.9% of all programs in real life, it is not only possible to determine if it will halt or not, but it is in fact trivial.
And second, thank you for proving my point that people frequently misunderstand the implications of any given theory.
(which is not to say that there aren't any good projects, but the ones with crappy interfaces and lacking documentation are certainly in the majority...)
That's because people routinely misunderstand theory.
For example: "it is impossible to write a program that can determine if another program will halt or not" is often reworded as "it is impossible to determine if a specific, given program will halt or not", which is patently untrue.
The theory in this case appears to be, if I understand correctly: "it is impossible to make a complete copy of a message without it being detected." So they just figured they can make a partial copy, thereby side-stepping detection, but still getting a lot of information.
The theory is right; the implications of that theory (that therefore all communication using it must be secure) is not.
Here in the Netherlands (which, contrary to popular belief, is not a nation of potheads and perverts) we had the local equivalent of a district attorney who threw out his old computer - containing child porn. The computer was found and the content were made public.
The result? He was spoken to in a firm tone of voice, and was moved to a cushy job far from the public eye. THAT'S ALL. He was not fired. He was not prosecuted.
The reasoning behind this? Well, he had apparently not intended to download child porn, he was just downloading normal porn (which is perfectly legal) and had accidentally included child porn as well.
Now, let's see a normal citizen try that particular defense...
So if someone important, like a DA, is revealed on national TV to have downloaded child porn, it will just be swept under the rug. End of story.
Of course, maybe things are different in the US. If you believe that I want you to hear about this great bridge I'm selling...
Sitting on one of those for twenty minutes totally wrecks my knees, leaving me barely able to walk. So be warned, it has downsides as well...
How about a company willing to sell, at a reasonable price, just to recoup the massive cost needed to build the software in the first place? Just saying that replication and distribution costs are close to zero is only counting a very small part of the total cost.
Delivering a Ferrari to my door can be done for a few euro's (the cost of the gas for the trip from the garage to my house). Yet instinctively, most of us would realize that this is not going to happen unless I also pay for the design, production, marketing, and overal status of owning such a car.
Did they release the drivers for all the onboard hardware, though? What if we want to build our own Mars lander and mod the digger a bit, or use a different landing sequence?
Hello, let's have some perspective here. There are plenty of people who would rejoice if 700MB downloads of free operating systems were no longer possible. Those people have billions in the bank and enough political influence to make this happen.
So don't say that this is a bad side effect. I see it very much as an INTENDED side effect.
...and pegging the other PowerPC processor handling the framebuffer...Because this is a special, cheaper version of XP. If it were allowed on decent hardware it would eat badly into their sales of Vista.
So, YES, the fax machine is OLDER. Much older. And we all sincerely apologize for getting on your lawn!
It's right besides the Empire Scat Building!
I use that ten years old IDE because it is more pleasant to work with than the more recent versions.
.NET.
Something really simple that *really* annoys the hell out of me in any later version: in VS6, you can cancel the message window (i.e. make it disappear) by hitting escape. In later versions, you cannot.
In VS6 you can create keyboard macro's and bind them to any key you want. I've been looking for this option in later versions and could not find it.
In VS6, DevStudio was first and foremost a C++ environment with some other stuff thrown in. In later versions it is the other way around: the normal C++ stuff seems to be an afterthought, and the focus is on lots of other stuff I don't use and don't care about, like HTML and
The list was longer, but it has been a while since I last used those later versions.
Oh, and those "free" versions of yours? They aren't free for corporate use...