While programming I often realize that I need to add something before already typed code. For example I type the name of the variable:
input[0]
and then I realize that my array is of type string and I need to convert it. So, I move to the beginning of the word (with Ctrl-Left Arrow) and start typing
Convert.To|input[0]
with pipe used to show the position of my cursor. I get some suggestions from Intellisense, including the ToInt32() method I am looking for. But as long as I confirm this suggestion with Tab or Space, I get the following:
Convert.ToInt32(|)[0]
So, the text from the cursor position to the end of the word is substituted with suggestion, and this is definitely not what I want.
This problem is not specific for VS 2012 and might be due to some extensions I have installed, but my attempt to pursue its origin did not yield anything. I have following extensions installed: ReSharper, PowerCommands, Productivity Power Tools.
If you are entering an unrelated expression before an identifier, add a space before you start typing the new expression. This will prevent the completion from replacing the existing identifier.
For example, if | marks the caret, the following scenario would avoid the problem you are facing.
Convert.To| input
This code completion feature is designed to prevent the insertion of incorrect identifiers. If Visual Studio behaved like some other IDEs I know of, using the code completion feature in your original example would result in the insertion of ToInt32input, which would never be valid.
If you are interested in additional thoughts regarding this feature in general, I have described this as the Extend (default for Visual Studio) and No-extend (default for NetBeans, Eclipse, and others) modes in my blog article Code Completion filtering, selection, and replacement algorithms.
A two years later answer. But it might still be useful for some.
What helped for me in VS2015 (which might also work in VS2012) is to add the a space character to the list of 'Member List Commit Characters' in the Intellisense settings.
After this the characters after the cursor are not removed by an auto-completion.
When using "keyword search" in offline MSDN that came with VS2008, is there any way to exclude unnecessary classes / namespaces that I know beforehand is out of the scope of my search? The search "filter" seems way to broad for this purpose.
To be specific, when I search for a class, say "ListView", I DO NOT want System.Web.UI class to show up as the first suggestion just because it is the first one alphabetically, and instead would like to see System.Windows.Forms.ListView as the document that comes up. I guess I could live with going to search result and browse through to find the intended class, or maybe typing class names with full namespace... But it would make my life easier if I could either temporary or even permanently (I know I won't touch ASP.NET for a while) remove unnecessary classes from the search index.
TIA
After trying several options I found out that manually taking the .HXS files associated with the unneeded namespaces out of the MSDN directory (In my case, C:\Program Files\MSDN\MSDN9.0\1041) seems to do the trick. MSDN document explorer recreates help index on the next launch after the content of the directory was modified. So even in case you need the documentation again, you can restore the help by simply moving the files back into the original folder.
The files I moved to take out System.Web.UI documentations were:
fxref_system.web.ui.adapters.hxs
fxref_system.web.ui.desi_obilecontrols.converters.hxs
fxref_system.web.ui.design.hxs
fxref_system.web.ui.design.mobilecontrols.hxs
fxref_system.web.ui.design.webcontrols.hxs
fxref_system.web.ui.design.webcontrols.webparts.hxs
fxref_system.web.ui.htmlcontrols.hxs
fxref_system.web.ui.hxs
fxref_system.web.ui.mobi_s.adapters.xhtmladapters.hxs
fxref_system.web.ui.mobilecontrols.adapters.hxs
fxref_system.web.ui.mobilecontrols.hxs
fxref_system.web.ui.webcontrols.adapters.hxs
fxref_system.web.ui.webcontrols.hxs
fxref_system.web.ui.webcontrols.webparts.hxs
Was pretty surprised when I saw this kind of somewhat primitive and forcible method to be the most effective...
Type "listview NOT System.Web.UI.ListView" for example - without the quotes :)
This may be a stupid question, but here goes.
I've seen several projects using some translation library (e.g. gettext) working with plain english placeholders. So for example:
_("Please enter your name");
instead of abstract placeholders (which has always been my instinctive preference)
_("error_please_enter_name");
I have seen various recommendations on SO to work with the former method, but I don't understand why. What I don't get is what do you do if you need to change the english wording? Because if the actual text is used as the key for all existing translations, you would have to edit all the translations, too, and change each key. Or don't you?
Isn't that awfully cumbersome? Why is this the industry standard?
It's definitely not proper normalization to do it this way. Are there massive advantages to this method that I'm not seeing?
Yes, you have to alter the existing translation files, and that is a good thing.
If you change the English wording, the translations probably need to change, too. Even if they don't, you need someone who speaks the other language to check.
You prep a new version, and part of the QA process is checking the translations. If the English wording changed and nobody checked the translation, it'll stick out like a sore thumb and it'll get fixed.
The main language is already existent: you don't need to translate it.
Translators have better context with a real sentence than vague placeholders.
The placeholders are just the keys, it's still possible to change the original language by creating a translation for it. Because when the translation doesn't exists, it uses the placeholder as the translated text.
We've been using abstract placeholders for a while and it was pretty annoying having to write everything twice when creating a new function. When English is the placeholder, you just write the code in English, you have meaningful output from the start and don't have to think about naming placeholders.
So my reason would be less work for the developers.
I like your second approach. When translating texts you always have the problem of homonyms. Like 'open' can mean a state of a window but also the verb to perform the action. In other languages these homonyms may not exist. That's why you should be able to add meaning to your placeholders. Best approach is to put this meaning in your text library. If this is not possible on the platform the framework you use, it might be a good idea to define a 'development language'. This language will add meaning to the text entries like: 'action_open' and 'state_open'. you will off course have to put extra effort i translating this language to plain english (or the language you develop for). I have put this philosophy in some large projects and in the long run this saves some time (and headaches).
The best way in my opinion is keeping meaning separate so if you develop your own translation library or the one you use supports it you can do something like this:
_(i18n("Please enter your name", "error_please_enter_name"));
Where:
i18n(text, meaning)
Interesting question. I assume the main reason is that you don't have to care about translation or localization files during development as the main language is in the code itself.
Well it probably is just that it's easier to read, and so easier to translate. I'm of the opinion that your way is best for scalability, but it does just require that extra bit of effort, which some developers might not consider worth it... and for some projects, it probably isn't.
There's a fallback hierarchy, from most specific locale to the unlocalised version in the source code.
So French in France might have the following fallback route:
fr_FR
fr
Unlocalised. Source code.
As a result, having proper English sentences in the source code ensures that if a particular translation is not provided for in step (1) or (2), you will at least get a proper understandable sentence than random programmer garbage like “error_file_not_found”.
Plus, what do you do if it is a format string: “Sorry but the %s does not exist” ? Worse still: “Written %s entries to %s, total size: %d” ?
Quite old question but one additional reason I haven't seen in the answers yet:
You could end up with more placeholders than necessary, thus more work for translators and possible inconsistent translations. However, good editors like Poedit or Gtranslator can probably help with that.
To stick with your example:
The text "Please enter your name" could appear in a different context in a different template (that the developer is most likely not aware of and shouldn't need to be). E.g. it could be used not as an error but as a prompt like a placeholder of an input field.
If you use
_("Please enter your name");
it would be reusable, the developer can be unaware of the already existing key for an error message and would just use the same text intuitively.
However, if you used
_("error_please_enter_name");
in a previous template, developers wouldn't necessarily be aware of it and would make up a second key (most likely according to a predefined wording scheme to not end up in complete chaos), e.g.
_("prompt_please_enter_name");
which then has to be translated again.
So I think that doesn't scale very well. A pre-agreed wording scheme of suffixes/prefixes e.g. for contexts can never be as precise as the text itself I think (either too verbose or too general, beforehand you don't know and afterwards it's difficult to change) and is more work for the developer that's not worth it IMHO.
Does anybody agree/disagree?
I use ReSharper's code cleanup all the time, but sometimes I have code formatted in a way that makes it easier to read than ReSharper's formatter makes it. Is there a way to mark part of your file with comments or something to make it skip formatting that portion.
(I'm not talking about inspections, I know how to have ReSharper ignore regions for inspections)
I had a discussion with Resharper support about this, their answer:
Thank you very much for this information! We will discuss if we can
support such formatting style in one of the future versions.
Probably not, but you can try writing your own Resharper plugin
As of writing this, you can actually do it the other way around. I.e., format only a selected area of code. Just select the desired block, hit Alt+Enter and type Format Selection. Meanwhile Silent Code Cleanup still cleans up the whole file. I agree, that a comment-styled exclusion would be very nice.
Yes, now it is, see this answer and this feature request:
// #formatter:off
... Code you don't want formatted here ...
// #formatter:on
Some of my colleagues use special comments on their bug fixes, for example:
// 2008-09-23 John Doe - bug 12345
// <short description>
Does this make sense?
Do you comment bug fixes in a special way?
Please let me know.
I don't put in comments like that, the source control system already maintains that history and I am already able to log the history of a file.
I do put in comments that describe why something non-obvious is being done though. So if the bug fix makes the code less predictable and clear, then I explain why.
Over time these can accumulate and add clutter. It's better to make the code clear, add any comments for related gotchas that may not be obvious and keep the bug detail in the tracking system and repository.
I tend not to comment in the actual source because it can be difficult to keep up to date.
However I do put linking comments in my source control log and issue tracker. e.g. I might do something like this in Perforce:
[Bug-Id] Problem with xyz dialog.
Moved sizing code to abc and now
initialise later.
Then in my issue tracker I will do something like:
Fixed in changelist 1234.
Moved sizing code to abc and now
initialise later.
Because then a good historic marker is left. Also it makes it easy if you want to know why a particular line of code is a certain way, you can just look at the file history. Once you've found the line of code, you can read my commit comment and clearly see which bug it was for and how I fixed it.
Only if the solution was particularly clever or hard to understand.
I usually add my name, my e-mail address and the date along with a short description of what I changed, That's because as a consultant I often fix other people's code.
// Glenn F. Henriksen (<email#company.no) - 2008-09-23
// <Short description>
That way the code owners, or the people coming in after me, can figure out what happened and they can get in touch with me if they have to.
(yes, unfortunately, more often than not they have no source control... for internal stuff I use TFS tracking)
While this may seem like a good idea at the time, it quickly gets out of hand. Such information can be better captured using a good combination of source control system and bug tracker. Of course, if there's something tricky going on, a comment describing the situation would be helpful in any case, but not the date, name, or bug number.
The code base I'm currently working on at work is something like 20 years old and they seem to have added lots of comments like this years ago. Fortunately, they stopped doing it a few years after they converted everything to CVS in the late 90s. However, such comments are still littered throughout the code and the policy now is "remove them if you're working directly on that code, but otherwise leave them". They're often really hard to follow especially if the same code is added and removed several times (yes, it happens). They also don't contain the date, but contain the bug number which you'd have to go look up in an archaic system to find the date, so nobody does.
Comments like this are why Subversion lets you type a log entry on every commit. That's where you should put this stuff, not in the code.
I do it if the bug fix involves something that's not straightforward, but more often than not if the bugfix requires a long explanation I take it as a sign that the fix wasn't designed well. Occasionally I have to work around a public interface that can't change so this tends to be the source of these kinds of comments, for example:
// <date> [my name] - Bug xxxxx happens when the foo parameter is null, but
// some customers want the behavior. Jump through some hoops to find a default value.
In other cases the source control commit message is what I use to annotate the change.
Whilst I do tend to see some comments on bugs inside the code at work, my personal preference is linking a code commit to one bug. When I say one I really mean one bug. Afterwards you can always look at the changes made and know which bug these were applied to.
That style of commenting is extremely valuable in a multi-developer environment where there is a range of skills and / or business knowledge across the developers (e.g. - everywhere).
To the experienced knowledgable developer the reason for a change may be obvious, but for newer developers that comment will make them think twice and do more investigation before messing with it. It also helps them learn more about how the system works.
Oh, and a note from experience about the "I just put that in the source control system" comments:
If it isn't in the source, it didn't happen.
I can't count the number of times the source history for projects has been lost due to inexperience with the source control software, improper branching models etc. There is
only one place the change history cannot be lost - and that's in the source file.
I usually put it there first, then cut 'n paste the same comment when I check it in.
No I don't, and I hate having graffiti like that litter the code. Bug numbers can be tracked in the commit message to the version control system, and by scripts to push relevant commit messages into the bug tracking system. I do not believe they belong in the source code, where future edits will just confuse things.
Often a comment like that is more confusing, as you don't really have context as to what the original code looked like, or the original bad behavior.
In general, if your bug fix now makes the code run CORRECTLY, just simply leave it without comments. There is no need to comment correct code.
Sometimes the bug fix makes things look odd, or the bug fix is testing for something that is out of the ordinary. Then it might be appropriate to have a comment - usually the comment should refer back to the "bug number" from your bug database. For example, you might have a comment that says "Bug 123 - Account for odd behavior when the user is in 640 by 480 screen resolution".
If you add comments like that after a few years of maintaining the code you will have so many bug fix comments you wouldn't be able to read the code.
But if you change something that look right (but have a subtle bug) into something that is more complicated it's nice to add a short comment explaining what you did, so that the next programmer to maintain this code doesn't change it back because he (or she) thinks you over-complicated things for no good reason.
No. I use subversion and always enter a description of my motivation for committing a change. I typically don't restate the solution in English, instead I summarize the changes made.
I have worked on a number of projects where they put comments in the code when bug fixes were made. Interestingly, and probably not coincidentally, these were projects which either didn't use any sort of source control tool or were mandated to follow this sort of convention by fiat from management.
Quite honestly, I don't really see the value in doing this for most situations. If I want to know what changed, I'll look at the subversion log and the diff.
Just my two cents.
If the code is corrected, the comment is useless and never interesting to anybody - just noise.
If the bug isn't solved, the comment is wrong. Then it makes sense. :) So just leave such comments if you didn't really solved the bug.
To locate ones specific comment we use DKBUGBUG - which means David Kelley's fix and reviewer can easily identity, Ofcourse we will add Date and other VSTS bug tracking number etc along with this.
Don't duplicate meta data that your VCS is going to keep for you. Dates and names should be in the automatically added by the VCS. Ticket numbers, manager/user names that requested the change, etc should be in VCS comments, not the code.
Rather than this:
//$DATE $NAME $TICKET
//useful comment to the next poor soul
I would do this:
//useful comment to the next poor soul
If the code is on a live platform, away from direct access to the source control repository, then I will add comments to highlight the changes made as a part of the fix for a bug on the live system.
Otherwise, no the message that you enter at checkin should contain all the info you need.
cheers,
Rob
When I make bugfixes/enhancements in third party libraries/component I often make some comments. This makes it easier find and move the changes if I need to use a newer version of the library/component.
In my own code I seldom comments bugfixes.
I don't work on multi-person projects, but I sometimes add comments about a certain bug to a unit test.
Remember, there's no such thing as bugs, just insufficient testing.
Since I do as much TDD as possible (everything else is social suicide, because every other method will force you to work endless hours), I seldomly fix bugs.
Most of the time I add special remarks like this one to the code:
// I KNOW this may look strange to you, but I have to use
// this special implementation here - if you don't understand that,
// maybe you are the wrong person for the job.
Sounds harsh, but most people who call themselves "developers" deserve no other remarks.