In atom some special words such as TODO, FIXME, IDEA, NOTE, ... are automatically highlighted in comments inside code. I want to add some words to this list, how can I do?
All of the words you have identified are implemented by the atom/language-todo package and supports TODO, FIXME, CHANGED, XXX, IDEA, HACK, NOTE, and REVIEW words in comments.
language-todo has subsequently been extended to include some extra words in the dkiyatkin/language-todo-extra-words package to include: INFO, DEBUG, REMOVE, OPTIMIZE, UNDONE, TO DO, REFACTOR, DEPRECATED, TASK, CHGME, NOTREACHED, WTF, BUG, ERROR, OMG, ERR, OMFGRLY, WARNING, WARN and BROKEN.
If you wanted even more words then you could extend the grammars of one of the above packages to support the words you would like to see supported. If you need some help with this then feel free to post questions using the atom-editor tag on Stack Overflow or on the Atom Discussion Boards.
I recommend also todo-show. To open it use Ctrl+Shift+T. Is shows list of all todos in project. Yo can redefine keywords it looks for. It's realy nice to manage all todos in project.
Related
I was reading the template documentation of rsyslog to find better properties and I stumble upon this one:
spifno1stsp - expert options for RFC3164 template processing
However, as you can see, the documentation is quite vague. Moreover, I have not been able to find a longer explanation anywhere. The only mentions found with Google are always about the same snippet or the same very short description.
Indeed, there is no explanation of this property:
on the entire rsyslog.com website,
or in the RFC3164,
or anywhere else actually.
It is like everybody copy & paste the same snippet here and there but it is very difficult to understand what it is actually doing.
Any idea ?
Think of it as somewhat like an if statement. If a space is present, don't do anything. Otherwise, if a space is not present, add a space.
It is useful for ensuring that just one space is added to the output, often between two strings.
For any cases like this that you find where the docs can be improved please feel free to open an issue with a request for clarification in the official GitHub rsyslog documentation project. The documentation team is understaffed, but team members will assist where they can.
If you're looking for general help, the rsyslog-users mailing list is also a good resource. I've learned a lot over the years by going over the archives and reading prior threads.
Back to your question about the spifno1stsp option:
While you will get a few hits on that option, what you'll probably find more results on is searching for the older string template option, sp-if-no-1st-sp. Here is an example of its use from the documentation page you linked to:
template(name="forwardFormat" type="string"
string="<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
)
Here is the specific portion that is relevant here:
`%msg:::sp-if-no-1st-sp%%msg%`
From the Property Replacer documentation:
sp-if-no-1st-sp
This option looks scary and should probably not be used by a user. For
any field given, it returns either a single space character or no
character at all. Field content is never returned. A space is returned
if (and only if) the first character of the field’s content is NOT a
space. This option is kind of a hack to solve a problem rooted in RFC
3164: 3164 specifies no delimiter between the syslog tag sequence and
the actual message text. Almost all implementation in fact delimit the
two by a space. As of RFC 3164, this space is part of the message text
itself. This leads to a problem when building the message (e.g. when
writing to disk or forwarding). Should a delimiting space be included
if the message does not start with one? If not, the tag is immediately
followed by another non-space character, which can lead some log
parsers to misinterpret what is the tag and what the message. The
problem finally surfaced when the klog module was restructured and the
tag correctly written. It exists with other message sources, too. The
solution was the introduction of this special property replacer
option. Now, the default template can contain a conditional space,
which exists only if the message does not start with one. While this
does not solve all issues, it should work good enough in the far
majority of all cases. If you read this text and have no idea of what
it is talking about - relax: this is a good indication you will never
need this option. Simply forget about it ;)
In short, sp-if-no-1st-sp (string template option) is analogous to spifno1stsp (standard template option).
Hope that helps.
One thing that constantly annoys me about VS is that when I do a Find or Find all, it looks in comments, strings, and other places. When I'm trying to find a particular bit of code, like and rent, it finds it all over. Is there a way to limit searches just to code?
Not sure if there is a specific setting to ignore comments, but you could do a regex find. For example, assuming you want to find "text", you could use this:
^(?!\s*?//).*?text
Caveats:
Assumes comments start with // as first non-whitespace characters. E.g. C# comment types
Doesn't work for comments at the end of code lines (only comments on their own lines)
Doesn't work with block comments, for example /* comment */
So overall it isn't perfect by any means, but depending how many hits you are getting, it might help to cut them down which can be useful if you have a lot of false positives in one-liner comments
The 'Find All References' function may suit you : it ignores all commented-out code and text in strings. CTRL+K, R is the keyboard shortcut.
(Note that it's designed for going from a specific instance of a search string to all other instances. so if you haven't already found an instance of what you're searching for, you would have to (temporarily) type one in to the editor window, then search. Also it's not available for all languages : I know it works fine for C#, though.)
In the latest code review I was asked, why did I change the method name from GetHDRFrame to GetHdrFrame, while HDR is an abbreviation. I'm pretty sure there was such recommendation in Code Complete: when using abbreviations in CamelCase names, treat them as regular words. But I cannot find the place where it is written. Could somebody give me an exact phrase in Code Complete, where it is stated?
There is a similar question with the useful links to MS rules, but I'm looking for Code Complete quote.
As far as I've been able to determine, there is no such advice in Code Complete. But it does say:
People have managed to have zealous, blistering debates over fine
points such as whether the first character in a name should be
capitalized (TotalPoints vs. totalPoints), but as long as you and
your team are consistent, it won't make much difference.
And that may help you avoid such nitpicking in future code reviews. ;-)
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 am refactoring a C++ codebase in Visual Studio 2005. I'm about half way through this process now and I've commented out a lot of old code and replaced or moved it. Now I'm searching to see that I have to change next but the search function keeps bringing me the old commented out stuff I no longer care about. I don't really want to delete that old code yet, just in case.
Is there any way I can search all files in the solution and get results ignoring what is commented out? I don't see a way in visual studio itself, is the perhaps a plug-in that would do it?
As the other provided solutions didn't work for me, I finally discovered the following solution:
^~(:b*//).*your_search_term
Short explanation:
^ from beginning of line
~( NOT the following
:b* any number of white spaces, followed by
// the comment start
) end of NOT
.* any character may appear before
your_search_term your search term :-)
Obviouly this will only work for // and ///-style comments.
You must click "Use Regular Expressions " Button (dot and asterisk) on your find window to apply regex search
In newer versions of visual studio .net regex is used which has a slightly different syntax:
^(?![ \t]*//).*your_search_term
My take:
yes you can use regular expressions, those tend to be too slow and thinking about them distracts from focusing on real stuff - your software.
I prefer non-obtrusive semi-inteligent methods:
Poor man's method:
Find references if you happen to use intelisense on
Or even better:
Visual assist and it's colored "Find all References" and "Go To" mapped to handy shortcuts. This speeds up navigation tremendously.
If you comment your old code with // you can use regular expressions while searching for something in your codebase. Something like this for example: ^[^/][^/].*your_function_name.*.
Previous answer gave a false-positive on cases where otherwise matching lines were placed on lines containing other source:
++i; // your_search_term gets found, don't want it found
So replaced the :b* with .* and added the <> so only entire words are found, and then went after some of the older C-style comments where there's a /* on the line:
^~(.*//)~(.*/\*).*<your_search_term>
In my case I was hunting for all instances of new, not amenable to refactor assistance, and boatloads of false-positives. I also haven't figured out how to avoid matches in quoted strings.
Just to add on, as I was doing a "find all" for division operator used in the code, used the below to exclude comments as well as </ and /> from aspx files:
^~(.*//)~(.*/\*)~(.*\<\/)~(.*/\>).*/
In Visual Basic within Visual Studio 2015, I was able to search for text outside of comments by adapting glassiko's comment from the most upvoted answer
^(?![ \t]*[']).*mysearchterm
And in C# you would use glassiko's comment exactly as it was
^(?![ \t]*//).*mysearchterm
Better use \s I think. ^(?![\s]*//).*your_search_term
delete the commented out code, it is in source control right? there is no need to keep it in the file as well.