I really like that WebStorm and PhpStorm IDEs from JetBrains will check for typos in my code. The problem I have is that throughout the codebase, I have hundreds of random strings formatted like this: [XXXXXX] where X is an alphanumeric character (0-9 or A-Z). The IDE informs me that these are typos and these false-positive warnings make real typos difficult to find.
I don't know how to tell the IDE to ignore these strings. I've considered:
Adding the strings to the dictionary: this carries a high overhead because there are hundreds, and as the codebase expands there will be hundreds and eventually thousand+ more
Disabling typo check: this isn't a good solution because I still want the IDE to alert me of typos
Is there a good solution to this? Maybe a setting to consider all strings that fit a particular RegEx as valid, or to ignore typo checks for all such strings?
Related
Is there any safe way to automate this process for multiple files? By safe I want that this will not break the code or introduce some kind of weird side effects that will manifest exactly when you don't want it in production.
I know about http://man.cx/expand. Is this method truly safe?
expand is pretty good, but I seem to recall it can get tricked in some conditions / for some languages, so for safety I'd have to assume "not truly".
Hopefully, however, your source code has plenty of tests before it goes to Production to demonstrate its full functionality and correctness.
Alternatively / additionally, if you're compiling or producing bytecode (e.g. Java), you could probably do a binary comparison of the artefacts to prove equivalence between the original and that produced from the de-tabbed source code.
I have legacy xml files with html entities such as — etc. How can I convert this entities to hex equivalent such as —. Is there any easy way to do this using a batch command or something else? I am not high level programmer so any detail help will be appreciated.
Just a simple find and replace may be all you need. Most, if not all text/code editors have a find/replace function.
Chances are that there are only a few characters strings that make up the majority of what you need to replace and fortunately, they're all pretty unique so it's unlikely that you'll have any accidental replacements.
Well, I think YAML is really fantastic...
It's beautiful, easy to read, clever syntax...compared to any other data serialization format.
As a superset of JSON we could say it's more elaborated, hence its language evolution.
But I see some different opinions out there, such:
YAML is dead,
don't use yaml and so on...
I simply can't understand on what this is based because it seems so nice :)
If we take few well succeeded examples over the web such as Ruby on Rails, we know they use yaml for simple configuration, but one thing that gets me curious is why yaml is not being part of most used formats over web like XML and JSON.
If you take twitter for example...why not offer the data in YAML format from the API as well?
Is there something wrong by doing it?
We can see the evolution on no-sql databases like couchdb, mongo, all json based, even one great project called jsondb which looks very lightweight and it definitely can do the job.
But when writing data structures in json I really can't understand why YAML is not being used instead.
So one of my concerns would be if is there something wrong with YAML?
People can say it's complex, but well, if you pretend to use the same features you would get in json it's definitely not. You will get a more beautiful file for sure tho and with no hassle. It would be indeed more complex if you decide to use more features, but that's how things are, at least you have the possibility to use it if you want to.
The possibility to choose if you want or not to use double-quotes for string is fantastic makes everything cleaner and easier to read....well you see what's my point :)
So my question would be, why YAML is not vastly used in place of JSON?
Why it doesn't seem that it will be used for data structure transfers within the online community?
All I can see is people using it for simple configuration files and nothing else...
Please bear with me since I might be completely wrong and very big projects might be happening and my ignorance on the subject didn't allow me to be a part of it :)
If is there any big project based on yaml out there I would be very happy to know about it
Thanks in advance
It's not that there's something wrong with YAML — it's just that it doesn't offer any compelling benefits in many cases. YAML is basically a superset of JSON. For most purposes, JSON is quite sufficient — people wouldn't be using advanced YAML features even if they had a full YAML parser — and its close ties to JavaScript make it fit in well with the technologies that Web developers are using anyway.
TLDR: People are already using as much YAML as they need. In most cases, that's JSON.
YAML uses more data than non-prettified JSON. It's great for files that humans might want to edit themselves but when all you're doing is passing data around, you're wasting bandwidth if you're using YAML.
If you need an explanation: each space in UTF-16 is two bytes. YAML uses spaces for indentation, and newline characters for nesting.
Take this example:
foo:
bar:
- foo
- bar
This requires 44 characters (including newline characters). The equivalent JSON would be only 29 characters:
{"foo":{"bar":["foo","bar"]}}
Then just imagine what happens if you URL-encode the YAML. It becomes 95 characters:
foo%3A%0A%20%20%20%20bar%3A%0A%20%20%20%20%20%20%20%20-%20foo%0A%20%20%20%20%20%20%20%20-%20bar
Meanwhile the JSON just becomes 64 characters:
%7B%22foo%22%3A%7B%22bar%22%3A%5B%22foo%22%2C%22bar%22%5D%7D%7D
The size increase to YAML from JSON is more than double when it's URL-encoded, in the above example. And I'm sure you can just imagine that the longer your YAML file, the more and more this difference will increase.
Oh, and one other reason not to use YAML: stackoverflow.com does not support YAML syntax highlighting... ! (Of course, I would argue that YAML is so beautiful that it doesn't need syntax highlighting. That's kind of the point of YAML, I think.)
In Ruby many people argue that configuration should be Ruby, rather than YAML. This saves the parsing stage, means you don't have to learn the new syntax, and don't end up with ERB tags everywhere when you are dynamically generating YAML content (Rails fixtures).
Personally I have to agree, and can't see what YAML would offer to network transfers that would make it a worthwhile consideration over JSON.
YAML has an amount of problems, there is a good article
YAML: probably not so great after all on that.
Short summary (in addition to problems already listed in other answers):
Unreadable except for simple and short things
Insecure by default
Has portability issues
Very complex, with amount of surprising behaviors
I considered using YAML few times and never did. The reason always had to do with white spaces for indentation. While I personally love this, even to me it sounded like asking for trouble, because
For sure someone will make a mistake, not expecting that changing white spaces will break the file. Sometimes someone who has no idea about the language / format has to go to the file to change one number or string.
You can't guarantee that everybody everywhere will have it's comparison / merging / SC software configured properly to catch white space or empty lines differences.
Are there any microscopic reasons at all (beyond superstition), to add an extra return after </html> in (X)HTML documents?
Is there any significant reason at all, not to stop this habit of mine? (To me, it looks a lot cleaner with the last line number being the same as the last bit of code, but I'm curious to know if there are any known consequences/possible effects between keeping or not keeping the extra return, such as the last line not being interpreted or something like that.)
It's just superstition. If I remember correctly, one of the earlier IE versions (2 or 3) would throw an error if you didn't have an extra line break there, but I think that hasn't mattered for quite some time.
One reason is because some lazily-programmed parsers are programmed to read a line at a time using linefeed or carriage-return-line-feed, and if the data stream just ends then it either won't parse the last line or it will just fail. I have experienced some C compilers and some versions of Make will complain if the last line doesn't contain a linefeed. Obviously these are not HTML, but the reason holds.
I always add an extra linefeed out of habit for this reason.
Are you using a VCS? Historically, some version control systems moan about a missing line end at end-of-file; I believe this may be due to diff and patch being (originally) a bit fussy about this.
Not exactly superstition; perhaps we could classify it as an obsolete urban legend (plenty of those in this business).
I always end my files with a linefeed.
At one time I had a automatic tool that would concatenate all JavaScript files in a directory into a single file (to save HTTP requests). This would break if a file didn't end in a newline and also didn't end with a semicolon.
Ever since then I've ended files with a newline.
Also, if you use a command line shell like bash, and you cat a file; The new prompt will appear after the last character in the file, so it looks a lot better if that's a newline.
It makes no difference
Nope, like Patrick says it doesn't matter. The entire page can be on one line if you want.
One thing's for sure, no modern well-known browser is going to care. Indeed in HTML, as opposed to XHTML, the </html> tag is superfluous too.
However, in your first sentence you ask for microscopic reasons and I have one. Some editors (I think notepad used to be one, I haven't checked lately) will automatically add a CR/LF to the last line of a file on save if the line is not empty, probably to fix problems such as the ones DevelopersDevelopersDevelopers describes. This used to be a real irritation when editing DOS batch files as an extra line could adversely affect the way the script terminated.
As a result, if you create your HTML in one editor which doesn't do this, and you don't manually add the final CR/LF, then later someone opens the file in a editor which does, doesn't change anything and saves, you get an erroneous difference that can show up in when searching for real changes or in version control logs.
In your second sentence, you ask for significant reasons. This is not, IMO, a significant reason, and I certainly would bother about such an edge case.
I don't think there is any good reason. Maybe without the return less data is transmitted so you can save traffic. But I don't think this matters at all ;-)
What language(s) have comments with side effects? In essence, comments which are not comments....
English. Do I win?
DOS Batch Shell programming
The REM (Remark) allows you to put in a comment. But it has the side-effect of modifying the ERRORLEVEL variable to 0.
In a sense, it makes last operation a success.
I don't know how a comment can fail, but if it does, you are covered.
I can think of several places where comments aren't really comments.
HTML and script tags (providing support for browsers that don't allow or support scripts).
And then, considerably more obscurely:
IBM Informix 4GL (I4GL) and 4J's Genero (successor to Informix Dynamic 4GL, D4GL). The notation '--#' was used by D4GL to include material only applicable to D4GL; I4GL would see that as a comment. The inverse notation was '--#', which looked like a comment to D4GL but was treated as active material by I4GL.
And, even more obscurely:
I wrote an I4GL file which was dual-languaged, exploiting I4GL's multiple comment facilities. Material starting '#' (hash) marked the start of a comment outside of strings - up to the next newline, as does '--' (double-dash). Also, '{...}' (braces) enclose multiline comments.
The top of the source file was actually a shell script, mostly enclosed in '{...}' which is, of course, perfectly legitimate in shell. The shell script was a data-driven code generator that copied itself to the top of the output, and then generated about 100 functions which were all depressingly similar but slightly different (in a language without templates or a pre-processor). The code had to validate what was in the database for a given ship against incoming data from an external source (Lloyds of London, in fact), to see what had changed since the last time the external data was received. Non-trivial comparison work, especially since it had to deal with database (SQL) nulls.
The file was not really a Quine program, but it had some points in common with it. In particular, you could feed the script broken I4GL code and the regenerated file would be perfect again, basically because it ignored the existing I4GL code.
Haskell can turn the usual comments in code paradigm upside down by having code in comments - also Mathematica and the like; literal programming is a nice feature for the more mathematically inclined languages.
I also find annotations in Java are like comments with behaviour.
Then of course there are "polyglots" -- programs which can be compiled/executed in multiple languages. Usually these rely on the fact that the same line is a comment in one language, but an actual line of code in another.
QBasic has a use of comments all its own: REM $STATIC or REM $DYNAMIC set how arrays are allocated.
Another example: When web browsers parse comments <!-- -- -->in<!-- -- -->correctly.
CSS for clever cross-browser hacks. Of course, I wouldn't really call CSS a language.
Just stumbled upon this old question and my first thought was javadoc comments.