In my code I got a bunch of bugs lately due to typing things like if(a = b).
This may sound silly, but I really do need a rule to get rid of this.
especially when I type array.find(val => val.id = 0).
I know that there is a rule to enforce boolean expressions in simple statements like if and for and so on...
But is there also a rule which enforces the same in like funtions?
you can add "triple-equals": true in your tslint.json file to enforce the triple equals.
Related
I'm very new to typescript and I'm trying to learn the language.
I'm reading through a component and I see this:
interface FilterRowProps {
cannotRemove: boolean
filterName?: string
}
const field = getField(demo.fields)(filterName!)
Questions:
This made me think, What is ! in typescript signified for?
What happens if it's not passed (optional parameter?) does it throw an error or does it not do anything?
Does it make sense to make argument optional and use ! inside component?
Since filterName props is optional, what does filterName! signify?
Can someone explain? Super confused.
The ! is the non-null assertion operator. It tells typescript "i know this looks like it might be null/undefined, but trust me, it's not". This is occasionally needed in cases where typescript can't figure out that your code eliminates the possibility of a null or undefined.
But be aware that like any type assertion, you are telling typescript not to check your work. If you use it, and it actually can be null/undefined, typescript will not alert you to this fact, and you may get an error at runtime.
In short: you should rarely use this. Most of the time, if the types lead typescript to deduce that it might be undefined, then it's probably right. You should then write code to deal with the undefined.
I have an argument with my compilation course lecturer:
In the test that was part of this course, some of the questions referred the identification and classification code segments written in C.
Each of these questions must indicate at what stage the error will expose:
a.Lexical analysis
b. Synthetic analysis
c. Semantic analysis
d. Running time (under certain conditions)
e. This is not an error.
One of the questions in this style was as follows:
Switch command that does not have the default component. For example:
switch (key){
case 1: .........
case 2: .........
case 3:..........
}
Now, in the official test solution, in the above case only option e was correct.
However, I argue that Option d cannot necessarily be rejected outright, and that it is also true.
As an argument, I showed (after the test) the following two examples to my lecturer:
1)
(from : https://cwe.mitre.org/data/definitions/478.html)
2)
(from : Should switch statements always contain a default clause?)
However, he is not yet convinced that the runtime error option is considered in this case. He said that because of the questions mentioned above, it is only for commands or snippets that are shown directly in the questions and because the code does not have the intent of the code, so in this case they are actually asking if this structure is by itself invalid, so you are denied a runtime error here (I personally do not notice any contradictory here ...).
I would be happy if you could share your views on this issue.
Your lecturer is correct.
Omitting the default case in a switch is perfectly valid code and will not directly lead to any kind of problem. It may well be exactly what the programmer intended, and do the correct thing.
Of course, it is always possible to add some code that would cause problems, but that is a problem with this added code, not with the switch per se. Code style rules like "always add a default case" may guard against certain types of programming mistakes, but not following them does not automatically cause these mistakes - it "just" requires more caution.
From a code style perspective, it is usually better to be explicit about intentionally ignoring certain cases, or to add some default handler for guarding against unexpected values, but that does not mean that omitting such a handler is always incorrect by itself.
(Note that the currently second most upvoted answer in the question you linked to yourself argues for omitting default cases that are not doing anything useful, in order to reduce clutter - I don't fully agree with that, but it is a matter of style)
Using CakePHP 3.7.
I have added, at the bottom of config/bootstrap.php:
Inflector::rules('irregular', ['thesis' => 'theses']);
and actually, I've tried
Inflector::rules('irregular', ['theses' => 'thesis']);
just in case I had it backwards.
And in a cell I am trying to use:
use Cake\Utility\Inflector;
$singular_and_plural = [Inflector::singularize($base_name), $base_name];
The result for singularizing the word "thesis" is "thesiss".
Can anyone point out what's wrong, here?
The first form is the correct one, the key is the singular value, and the value the plural value.
That being said, what you're showing here is incorrect/problematic usage of Inflector::singularize(), as you're passing a value to it that already is singular, doing that often gives you unexpected/wrong results. You could open an issue ticket in such cases, sometimes this can be fixed in the core, but often times it's simply not possible as it would conflict with existing, required rules.
It should also be noted that CakePHP can handle thesis/theses out of the box already, it has singular/plural rules that match that. Make sure that you are passing in the expected values, and that you don't have additional custom rules that may interfer with what you're trying to inflect.
I found two lines in my code.
test = new qx.ui.form.RadioGroup;
I am wondering, if the missing () might cause issues or should maybe raise a warning in the generator or the lint job.
qx.ui.form.RadioGroup;
I think it might be worth reporting it as a "statement without effect" in lint.
mck89's comment is the answer (I wonder why so many people put valid answers in comments...):
You don't need the parens, and new qx.ui.form.RadioGroup is a syntactically correct expression, equivalent to adding a pair of empty parens. (There are some checkers that will warn about this, like I believe JsLint, but qooxdoo doesn't ... :).
In your particular case, the code will also run successfully in the browser, as RadioGroup permits empty constructor args; you can use .add() later to add items to the group.
I have some programs which make heavy use of libraries with enumerations of error codes.
The kind where 0(first value of enum) is success and 1 is failure. In some cases I have my own helper functions that return bool indicating error, in other cases I bubble up the error enumeration. Unfortunately sometimes I mistake one for the other and things fail.
What would you recommend? Am I missing some warnings on gcc which would warn in these cases?
P.S. it feels weird to return an error code which is totally unrelated to my code, although I guess I could return -1 or some other invalid value.
Is it a bad idea? No, you should do what makes sense rather than following some abstract rule (the likes of which almost never cater for all situations you're going to encounter anyway).
One way I avoid troubles is to ensure that all boolean-returning function read like proper English, examples being isEmpty(), userFlaggedExit() or hasContent(). This is distinct from my normal verb-noun constructs like updateTables(), deleteAccount() or crashProgram().
For a function which returns a boolean indicating success or failure of a function which would normally follow that verb-noun construct, I tend to use something like deleteAccountWorked() or successfulTableUpdate().
In all those boolean-returning cases, I can construct an easily readable if statement:
if (isEmpty (list)) ...
if (deleteAccountWorked (user)) ...
And so on.
For non-boolean-returning functions, I still follow the convention that 0 is okay and all other values are errors of some sort. The use of intelligent function names usually means it's obvious as to which is which.
But keep in mind, that's my solution. It may or may not work for other people.
In the parts of the application that you control, and the parts that make up your external API I would say, choose one type of error handling and stick to it. Which type is less important, but be consistent. Otherwise people working on your code will not know what to expect and even you yourself will scratch you head when you get back to the code in a year or so ;)
If standardizing on a zero == error scheme, you can mix and match both enum and bool if you construct your tests like this:
err = some_func();
if !err...
Since the first enum evaluates to zero and also the success case it matches perfectly with bool error returns.
However, in general it is better to return an int (or enum) since this allows for the expansion of the error codes returned without modification of calling code.
I wouldn't say, that it's a bad practice.
There's no need to create tons of enum-s, if you just need to return true/false, and you don't have other options (and true and false are explanatory enough ).
Also, if your functions are named OK, you will have less "mistakes"
For example - IsBlaBla - expects to return true. If you have [Do|On]Reload, a reload could fail for many reasons, so enum would be expected. The same for IsConnected and Connect, etc.
IMHO function naming helps here.
E.g. for functions that return a boolean value, is_foo_bar(...), or for functions that return success or an error code, do_foo_bar(...).