One of our designers likes to use mac smart quotes/apostrophes in his mockups, but we don't want them showing up ANYWHERE in the code. Is there a way to create a rule using TSLint that will warn (or even ban) specific characters like this from the entire codebase?
Smart quote example: you’ll
Dumb quote example: you'll
As you can see, it's pretty hard to see the difference and catch them in real time. They don't cause errors, but for consistency we don't want them finding their way in from copy/pastes.
It seems that there is no rule that provides character banning. You can write custom rule as described in the documentation.
See also https://stackoverflow.com/a/40394298/3639633 .
Related
Working on testing a React component, I was reading the docs and found scryRenderedDOMComponentsWithClass. I'm having trouble understanding the function of this component because it's unpronounceable, so I don't understand how it's naming maps to a mental model of what it's doing. (There are a number of related names, such as scryRenderedDOMComponentsWithTag.)
What does the scry part of this method name refer to? Scary? Scurry? What concept is this name trying to illustrate?
Short answer
"Scry" in this context just means "find all". See this comment on ReactTestUtils.scryRenderedComponentsWithClass. It's a single word, not an abbreviation, and it's pronounced like "cry" but with an "s" at the beginning.
Longer (and nerdier) answer
Elsewhere in that same file, you'll see a reference to DOM.scry:
/**
* Todo: Support the entire DOM.scry query syntax. For now, these simple
* utilities will suffice for testing purposes.
* #lends ReactTestUtils
*/
zpao explains in a comment on a GitHub issue:
That's a reference to an internal Facebook module. It's basically querySelectorAll with fallback behavior for handling old browsers and special cases. It is pretty unremarkable and doesn't actually translate super well here (except maybe a scryRenderedDOMComponentsWithQSA or something, but meh). We're working on improving the testing in other ways so I don't think there's anything we really want to do with this right now.
jimfb takes it a bit further in another GitHub issue, explaining that the name is a reference to Dungeons & Dragons:
Back in the day, we had a bunch of D&D fans on the team.
For reference:
http://www.dandwiki.com/wiki/SRD:Scrying
http://www.dandwiki.com/wiki/SRD3e:Scry_Skill
https://en.wikipedia.org/wiki/Scrying
Historically, we've used scry to indicate a helper that finds a set of results. As the framework matures, we should start choosing function names based on what the functions actually do instead of fantasy words that have very little meaning to the typical developer.
Though I would agree that the word has very little meaning to most, it's worth noting that "scry" is a real English word:
scry
[skrahy]
verb (used without object), scried, scrying.
to use divination to discover hidden knowledge or future events, especially by means of a crystal ball.
Interestingly, according to the data from Google's Ngram Viewer, it seems that the word fell out of normal usage in the early 19th century and then wallowed in obscurity until the 1980s, presumably after D&D gained popularity:
So I can't say I object to jimfb calling it a "fantasy word", especially considering the kind of imagery my imagination conjures up when I hear it.
I'm currently working on a project, which has to be MISRA 2012 compliant. But in the embedded world, you can't fulfill every MISRA rule. So I have to suppress some messages generated by QA-C. What's he best solution to do this?
I was thinking about making a table in every module header file with references (\ref and \anchor) to the relevant code lines, a description, etc. The first problem is: I can't use the Doxygen markdown table feature, because then the description has to be in one line, because Doxygen tables don't support line breaking. So I thought about using a simple verbatim table, what do you think?
Or is there a way to generate such a table automatically?
Greetings
m0nKeY
According to MISRA, all such undesired rules must be handled by your deviation procedure, given that they are either "required" or "advisory". You are not allowed to deviate from "mandatory" rules. (Strictly speaking, you don't need to invoke the deviation procedure for advisory rules.)
In my experience, the safest and smoothest way by far to do this, is to not allow individual deviations on case-by-case basis. All deviations from MISRA should be stated in your company coding standard, and in order to deviate you have to update that document. Which in turn enforces approval from the document owner, who is preferably the most hardened C veteran you have in the team.
That way, you prevent less experienced team members from misinterpreting the rules and ignoring important rules, simply because they don't understand them and mistake them for false positives. There should be a rationale in the document stating why the rule you deviate from is not feasible for your company.
This means that everyone in the dev team is allowed to deviate from the listed rules at any point, without the need to invoke any form of bureaucracy.
Once you have a setup like this, simply customize your static analyser and remove/ignore the undesired warnings. That way, you get rid of a lot of noise and false warnings from the tool.
To answer your question generally: To create an aggregate occurrence list of anything in doxygen, use \xrefitem
We use this as a tool in our code review process. I tag code with a custom tag \reviewme which adds the function to a list of all code in need of peer review. The next guy can come along and clear that tag. We have another custom tag \reviewedby which does not use \xrefitem but simply puts the reivewers name and the date in the code block saying who reviewed it and when. This had gotten a bit clunky as things have scaled with larget code bases and more developers. Now we're looking into tools that integrate with our version control process to handle this better. But when we started this it worked well and fit a shoestring budget. But that example should give you an idea of is capable.
Here is a screen shot of what the output looks like - proprietary stuff and auto names redacted:
Here is how we added this custom tag as an alias to xrefitem in our doxy file as follows
ALIASES = "reviewme = \xrefitem reviewme \"This section needs peer review\" \"Documentation block or code sections that need peer review\""
To add it from the GUI, you would go to Expert->Project->Aliases and add a line like this
reviewme = \xrefitem reviewme "This section needs peer review" "Documentation block or code sections that need peer review"
Same thing, just no need to put quotes around the whole thing and escape out the inner quotes.
\xrefitem is the underpinning of how things like \todo or \bug work in doxygen. You can make a list of just about anything your heart desires.
Speaking specifically to MISRA exceptions: Lundin's post has lot's of merit. I would consider it. I think a better place to document exceptions to coding standards is in the static analysis tool its self. Many tools have their own annotations where you can categorize the rule violation as 'excused' or whatever. But generally this does not remove them from the list, it allows you just to filter or sort them. Perhaps you can use REGEX in a script that runs prior to doxygen that will replace the tool specific annotation with a custom \xrefitem if you are really concerned. Or vice vera, replace the doxy annotation with your tool's annotation.
I'm currently creating a code named "SET". The code's name is an acronym, which has been defined for many (non programming) reasons, and therefore cannot be changed.
Problem: The easiest, and I believe the less painful way for the end-user to use my code would be naming the package "set".
But of course this is a problem since this conflicts with the built-in set function.
Question: What are the possible solutions? Some may be (there is probably more):
change the package name (eg. setb).
import setb
I would really really prefer not to, because then it will be different from the real name
make the package's name upper-case (SET)
import SET
It would be a straight forward solution, but I'm wondering: is this a pythonic proper naming for a package? Also, I find this a bit painful since all modules defined in the code will have something like "import SET.x.y..." (ie. upper-case, written a lot of times). But this is not a really big deal if this is a pythonic way.
keep the name "set"
import set
Well this is obviously not fine. But it would be a problem only if the user is using "import set", would not it be? This should not happen in "normal usage conditions", since the code will provides some scripts to use it, rather use it as a standard python module. But we never know, and it could be imported as it, and there may be even some problems I'm not seeing (with the built-in set).
I'm considering the solution 2., but I'm really not sure. Maybe this is not proper, or maybe you guys have a better solution.
PS: I've found some similar topics on the web and on stackoverflow, but it usually deals with names inside a script or module inside a package. The problem here is really related to the code's name (which is meaningful only written this way), and therefore related to the proper naming of the package's name.
EDIT
Selected solution: I've choosen to use "SET" as the package name. Although many good suggestions have been proposed here: pyset, semt, setool... or the more explicit "starexoplanettool" (expliciting the acronym). Thanks to you all.
EDIT #2
I like the "funny" solution of having a package named S, and a subpackage, E... to get finally:
import S.E.T
Thanks Don Question.
Why not spell out the meaning behind the acronym, and if the user is desperate for a shorter name, they can do import someetymologyterm as SET or whatever they prefer. Python gives them the choice, so it's not the end of the world either way.
Is this a pythonic proper naming for a package?
Under the circumstances, it doesn't matter.
Leading upper case is rare (ConfigParser, HTMLParser). Camel-case is rare (cStringIO).
But that doesn't make all upper-case wrong.
It just means you should pick a better acronym next time.
"set" is the English word with the largest number of definitions. It is the single poorest choice of acronym possible.
The point is not to conform to a community "standard" of more-or-less acceptable behavior.
The point is to write something that works.
(ie. upper-case, written a lot of times).
Hardly a concern. People actually run software more often than they write it.
People read and tweak more often than writing, also.
If you're worried about misspelling, there's copy and paste.
Also, even a cheap IDE like Komodo Edit can figure out how to code-complete an installed module with a long name.
If you have to choose such a misfortunate name, you could make the pain in the ass an ironic anathema! Just create a main-package "S" with a subpackage "E" and therein a subpackage "T".
Then you could do an:
import S.E.T
or
from s.e.t import xyz
or
import s.e.t as set_
you could even do some vodoo in the __init__.py file of the main-pacakge ;-)
Just my 2 cents!
Maybe I'm not getting it but this looks simply like a namespace problem.
Here is one way out. Prepend the path to the set.py onto the sys.path Before the import takes place. You can wrap this in a function which backs out the change after the import.
I'm in train so can't test this but that is what I would try.
Say I come up with some super-duper way of representing some data that I think would be useful for other people to know about and use. Assume I have a 'spec' in some form, even if it might not be a completely formal one: ie, I know how this file format will work already.
How would I then go about releasing this spec to get comments and feedback based on it? How would I get it 'standardised' in some form?
Specifying file formats is difficult. If the data you want to store is trivial, it tends to be trivial. In general however, this is hardly the case. You can use the RFC structure and keywords, but I always found specifying a fileformat in prose a slow, difficult and boring task, also because reading it is likewise difficult.
My suggestion, if you want to follow this way, is to focus on blocks of information. Most of the difficuly is for entities that are optional, and present only if another condition happens, so try to exploit this when partitioning your data.
The best spec, IMHO, is real code with an uberperfect testsuite.
As for standardization, if enough people use it, it becomes a de-facto standard. you don't need an official stamp for it, although when the format is used enough, you could benefit from an official mime type.
To talk about it, well, it depends. I found useful to talk in terms of "object oriented" entities, and also in terms of relationships. Database-like diagrams are very useful on this respect.
Finally, try to find a decent already standard alternative first, or at least try not to deal with the raw bits. There are a lot of perfect container formats out there that free you of many annoying tasks. The choice of the container depends on the actual type of file format (e.g. if you need encryption, interleaving, transactions, etc).
There are a couple of ways I'd go about it, I think.
First, determine if there's a standards body (like W3C, or IEEE) that might be related to your file format. If there is, pitch it to them. I have no idea how receptive they'd be though.
Second, a standard is useless if nobody is using it. Get some momentum behind it. Write a blog post, twitter and make a website about it. Link on programming.reddit.com, and slashdot. Describe it to your friends and colleagues. Post it here on SO, and ask for feedback.
HTH.
I'm using a WPF InkCanvas control to capture signatures in a Tablet PC application.
One of my requirements is to validate whether or not the application has really been "signed". Right now I'm doing this by checking the Strokes collection of the InkCanvas - if there are 0 strokes, then I know the user has not "signed".
However, if the user enters a single slash, or even a single dot, this counts as a stroke and my validation test will pass, even though the signature isn't really valid.
Any ideas about how to build a better test for this? Granted, the use case for what is and is not a valid signature is pretty fuzzy, but I want to try to eliminate obviously bad signatures.
Or is this simply unsolvable in any straightforward way?
I know there are algorithms to test if a signature is a valid match for an existing signature, like the one outlined here. However, finding out if something is a signature in the first place seems to be much more complex.
From Wikipedia:
On legal documents, an illiterate signatory can make a "mark" (often an "X" but occasionally a personalized symbol)
...
Several cultures whose languages use writing systems other than alphabets do not share the Western notion of signatures per se: the "signing" of one's name results in a written product no different from the result of "writing" one's name in the standard way. For these languages, to write or to sign involves the same written characters. Three such examples are Chinese, Japanese, and Korean.
While this could be approached using Intelligent Character Recognition, I also know that my signature rarely looks like it has any characters in it. It's even worse if I am using one of those UPS or FedEx package singing pads. Next time a package arrives though I will try signing with just a dash and a dot and see if it allows it (Which I think it will allow since it's already close enough to that).
Because a signature may not match any recognizable words or characters, trying to 'validate' it any further then you currently are could actually be discarding some valid signatures. If for some reason you do still need to know if there is something more then a dot, take a look at validating instead that the signature fills a certain sized rectangle. That still may invalidate results that shouldn't be, so if you do attempt to add any validation to it make sure to document fully the expectations of a valid signature.