I don't understand the difference between RSCSS vs BEM. Someone says RSCSS and someone says BEM.
Pls let me know the difference that
RSCSS is just BEM extended with some additional thoughts and experience of the crew who created it.
For example RSCSS states
one level nesting to ping specificity a bit
no double dash / lodash on modifier / elements
etc.
you can treat RSCSS as one of BEM modification (with some additional hints).
When working with RSCSS you should think in components. Each piece of UI should be thought as an individual component.
example:
.signup-form {
.inputfield {
...
}
.submitbtn {
...
&.-inverted {
..
}
}
}
BEM methodology is based on the Block - Element - Modifier system, and here for every element unique selector should be used.
example:
.form { }
.form__input { }
.form__submit { }
.form__submit--wide { }
More about this theme read in this CSS formatting text.
Related
I'd like to add extension Coding to DSTU2 ClaimResponse.item.adjudication.code which has binding strength as Extensible. I have three formats and which one is proper, or if none of them, what is suggested format? Thanks.
a. Use FHIR code "system" with a new code value
"adjudication":[
{
"code":{
"system":"http://hl7.org/fhir/ValueSet/adjudication",
"code":"allowed"
},
"amount":{
"value":21,
"system":"urn:std:iso:4217",
"code":"USD"
}
}
]
b. Use custom code "system" with a new code value
"adjudication":[
{
"code":{
"system":"http://myhealth.com/ClaimResponse/adjudication#allowed",
"code":"allowed"
},
"amount":{
"value":21,
"system":"urn:std:iso:4217",
"code":"USD"
}
}
]
c. Use extension
"adjudication":[
{
"code":{
"extension":[
{
"url":"http://myhealth.com/ClaimResponse/adjudication#allowed",
"valueCode":"allowed"
}
]
},
"amount":{
"value":234,
"system":"urn:std:iso:4217",
"code":"USD"
}
}
]
Option b is the closest, but the system URL looks a little funky. Something like this would be better: "system":"http://myhealth.com/CodeSystem/adjudication-code"
The system should ideally be a URL that resolves to the code system definition (though it doesn't have to) and should apply to a set of codes, not the single code you're conveying. (While it's possible to have one-code code systems, it's more than a little unusual.)
Option a is wrong because we never send the value set URL as the Coding.system. Option c is unnecessary - with an extensible binding, you're free to use any codes that aren't already covered by the defined value set.
All that said, it's not clear that "allowed" makes sense as a value for "code" given the other options in the extensible value set. You might also look at the draft STU 3 version which eliminates "code" altogether. See if that design will meet your needs better, and if not, provide feedback when it goes to ballot this August.
I am in the process of documenting a PHP project using PHPDocumentor2. Ironically, PHPDoc's documentation isn't overly detailed. I fully understand how to comment files, classes, functions and variables, however if a variable or constant is being defined within an if statement how should I comment it?
Example:
if ($foo==$bar) {
define('FOOBAR',$foo);
} else if ($foo>$bar) {
define('FOOBAR',$bar);
} else {
define('FOOBAR',$foo+$bar);
}
Clearly I don't want to add 3 comments, and the documentation should really explain the if statement so logically the docBlock ought to go before the start of the if statement - this would be most aesthetically pleasing in code view - but the docBlock has to be on the line immediately before the "define". I can put it before the first one, but that looks odd.
if ($foo==$bar) {
/**
* FOOBAR Definition.
*
* Value of FOOBAR. Yada yada.
* #var int
*/
define('FOOBAR',$foo);
} else if ($foo>$bar) {
define('FOOBAR',$bar);
} else {
define('FOOBAR',$foo+$bar);
}
Any ideas?
It's possible that phpdoc2's expectation of #ignore behavior is different that phpdoc1's.
In phpdoc1, the #ignore tag effectively means "you see this next piece of code that contains a documentable element in it? just ignore that piece of code". This behavior did indeed allow for PandyLegend's example to work exactly as the code+docblocks are written above. The manual's example usage for #ignore actually matches PandyLegend's use case too (http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.ignore.pkg.html).
Judging from phpdoc2's behavior I see from using PandyLegend's example, I think phpdoc2 is thinking "you see the documentable element in this next piece of code? record its name, and ignore that element completely in this whole set of documentation".
My guess is that this issue really is just a different interpretation rather than a bug.
(https://github.com/phpDocumentor/phpDocumentor2/issues/583)
i'm just starting prototype, i was on jquery before.
I can't find easy examples on the internet about how :
Selecting all elements having the same id on a page
(I'm doing this but it only works for the first element : $('mydiv').hide() )
Selecting a div that is contained in another div by their id.
hiding all elements that have myClass class.
As mentioned above you shouldn't have the same ID on a page more then once. Besides being against standards it's a recipe for potential problems since you don't know how your JavaScript will react to it. Uses classes instead.
Selecting all elements having the same
id class on a page (i'm doing this but it
only works for the first element :
$('mydiv').hide() )
Use $$:
$$('.myclass')
Selecting a div that is contained in
another div by their id.
Use $$:
$$('div#outer div#inner')
hiding all elements that have myClass
class.
Use $$, each(), and hide()
$$('.myClass').each(function(d) {
d.hide();
});
$$ is your friend.
A few things i would add.
$$('.myClass').each(function(d) {
d.hide();
});
can be replaced with this:
$$('.myClass').invoke("hide");
Also, be careful with your use of $$, within a page with a large dom it is usually faster to target a parent element with $ and then use select() for your selector
so
$$('div#outer div#inner') etc....
can be rewritten like this:
$('parent_of_inner_and_outer').select('div#outer div#inner') etc....
This isn't particularly pretty, but if you run into a situation like I did recently, where there could potentially be multiple items with the same id on the page and you don't have the ability to change that, then something like this will work. In my case, I at least knew they were all in span tags.
var spans = $$('span');
for (i = 0; i < spans.length; i++) {
var span = spans[i];
if (span.id == 'add_bookmark_image_' + id) {
span.hide();
}
if (span.id == 'is_bookmarked_image_' + id) {
span.show();
}
}
How much information hiding is necessary? I have boilerplate code before I delete a record, it looks like this:
public override void OrderProcessing_Delete(Dictionary<string, object> pkColumns)
{
var c = Connect();
using (var cmd = new NpgsqlCommand("SELECT COUNT(*) FROM orders WHERE order_id = :_order_id", c)
{ Parameters = { {"_order_id", pkColumns["order_id"]} } } )
{
var count = (long)cmd.ExecuteScalar();
// deletion's boilerplate code...
if (count == 0) throw new RecordNotFoundException();
else if (count > 1) throw new DatabaseStructureChangedException();
// ...boiler plate code
}
// deleting of table(s) goes here...
}
NOTE: boilerplate code is code-generated, including the "using (var cmd = new NpgsqlCommand( ... )"
But I'm seriously thinking to refactor the boiler plate code, I wanted a more succint code. This is how I envision to refactor the code (made nicer with extension method (not the sole reason ;))
using (var cmd = new NpgsqlCommand("SELECT COUNT(*) FROM orders WHERE order_id = :_order_id", c)
{ Parameters = { {"_order_id", pkColumns["order_id"]} } } )
{
cmd.VerifyDeletion(); // [EDIT: was ExecuteWithVerification before]
}
I wanted the executescalar and the boilerplate code to goes inside the extension method.
For my code above, does it warrants code refactoring / information hiding? Is my refactored operation looks too opaque?
I would say that your refactor is extremely good, if your new single line of code replaces a handful of lines of code in many places in your program. Especially since the functionality is going to be the same in all of those places.
The programmer coming after you and looking at your code will simply look at the definition of the extension method to find out what it does, and now he knows that this code is defined in one place, so there is no possibility of it differing from place to place.
Try it if you must, but my feeling is it's not about succinctness but whether or not you want to enforce the behavior every time or most of the time. And by extension, if the verify-condition changes that it would likely change across the board.
Basically, reducing a small chunk of boiler-plate code doesn't necessarily make things more succinct; it's just one more bit of abstractness the developer has to wade through and understand.
As a developer, I'd have no idea what "ExecuteWithVerify" means. What exactly are we verifying? I'd have to look it up and remember it. But with the boiler-plate code, I can look at the code and understand exactly what's going on.
And by NOT reducing it to a separate method I can also tune the boiler-plate code for cases where exceptions need to be thrown for differing conditions.
It's not information-hiding when you extract or refactor your code. It's only information-hiding when you start restricting access to your extension definition after refactoring.
"new" operator within a Class (except for the Constructor) should be Avoided at all costs. This is what you need to refactor here.
Consider:
if (something) {
// Code...
}
With CodeRush installed it recommended doing:
if (!something) {
return;
}
// Code...
Could someone explain how this is better? Surely there is no benefit what so ever.
Isolated, as you've presented it - no benefit. But mark4o is right on: it's less nesting, which becomes very clear if you look at even, say a 4-level nesting:
public void foo() {
if (a)
if (b)
if (c)
if (d)
doSomething();
}
versus
public void foo() {
if (!a)
return;
if (!b)
return;
if (!c)
return;
if (!d)
return;
doSomething();
}
early returns like this improve readability.
In some cases, it's cleaner to validate all of your inputs at the beginning of a method and just bail out if anything is not correct. You can have a series of single-level if checks that check successively more and more specific things until you're confident that your inputs are good. The rest of the method will then be much easier to write, and will tend to have fewer nested conditionals.
One less level of nesting.
This is a conventional refactoring meant for maintainability. See:
http://www.refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html
With one condition, it's not a big improvement. But it follows the "fail fast" principle, and you really start to notice the benefit when you have lots of conditions. If you grew up on "structured programming", which typically recommends functions have single exit points, it may seem unnatural, but if you've ever tried to debug code that has three levels or more of nested conditionals, you'll start to appreciate it.
It can be used to make the code more readable (by way of less nesting). See here for a good example, and here for a good discussion of the merits.
That sort of pattern is commonly used to replace:
void SomeMethod()
{
if (condition_1)
{
if (condition_2)
{
if (condition_3)
{
// code
}
}
}
}
With:
void SomeMethod()
{
if (!condition_1) { return; }
if (!condition_2) { return; }
if (!condition_3) { return; }
// code
}
Which is much easier on the eyes.
I don't think CodeRush is recommending it --- rather just offering it as an option.
IMO, it depends on if something or !something is the exceptional case. If there is a significant amount of code if something happens, then using the !something conditional makes more sense for legibility and potential nesting reduction.
Well, look at it this way (I'll use php as an example):
You fill a form and go to this page: validate.php
example 1:
<?php
if (valid_data($_POST['username'])) {
if (valid_data($_POST['password'])) {
login();
} else {
die();
}
} else {
die();
}
?>
vs
<?php
if (!valid_data($_POST['username'])) {
die();
}
if (!valid_data($_POST['password'])) {
die();
}
login();
?>
Which one is better and easier to maintain? Remember this is just validating two things. Imagine this for a register page or something else.
I remember very clearly losing marks on a piece of college work because I had gone with the
if (!something) {
return;
}
// Code...
format. My lecturer pontificated that it was bad practice to have more than one exit point in a function. I thought that was nuts and 20+ years of computer programming later, I still do.
To be fair, he lived in an era where the lingua franca was C and functions were often pages long and full of nested conditionals making it difficult to track what was going on.
Then and now, however, simplicity is king: Keeping functions small and commenting them well is the best way to make things readable and maintainable.