I'm not sure which is the official website, I've found getbem.com and en.bem.info.
One suggests using -- for the modifier (Naming):
CSS class is formed as block’s or element’s name plus two dashes.
The other _ for the modifier (Modifier name):
A modifier name is delimited by a single underscore (_).
I know I can use either, and really it's just important to be consistent, but I like to try and use official specs whenever possible.
Which is the official website..?
Should I really be using -- or _ for modifiers..?
Which is the official website?
BEM started as an informal set of guidelines by Yandex, which they later formalized on en.bem.info, so in that regard en.bem.info is the "canonical" version of BEM.
With that said, there are many flavors of BEM, and I myself use a variant influenced largely by Harry Roberts and Nicolas Gallagher.
This brings me to your next question:
Should I really be using -- or _ for modifiers?
To that my answer is: you should be consistent in your usage, but you may use whatever character(s) you'd like for the variant of BEM that you're using. Just be sure that everyone on your team understands which variant you're standardizing on.
This is similar to using tabs vs two spaces vs four spaces (vs hotdogs). It doesn't actually make a difference beyond being something that people tend to have an irrationally strong personal preference for.
To help normalize people, I use an example syntax of a block, element, and modifier that shows what the variant is normalizing on:
I used to primarily use:
the-block__the-element--the-modifier
But I now prefer:
TheBlock_theElement-theModifier
for its brevity.
Related
I read in the Julia doc page https://docs.julialang.org/en/v1/manual/variables/#:~:text=Variable%20names%20must%20begin%20with,Sm%20math%20symbols)%20are%20allowed. :
Word separation can be indicated by underscores ('_'), but use of
underscores is discouraged unless the name would be hard to read
otherwise
My question is if there any reasons to discourage the usage of underscores? Thanks.
I don't think underscores are really discouraged in user code and for internal variables. It is mostly for being consistent with the style in Base Julia, which follows this, mostly. And consistency is good, right?
But if you create a package or module, then the interface normally consists of types and functions. Typenames have strong convetion that they should be CapitalCase. User-facing functions are normally lowercase without _, because they are supposed to be simple, brief and should express a single well-defined concept. A bit like the Unix philospophy: every function should do one thing, and do it well.
A convention discouraging composite and long identifier names encourages you to create simple functions. If your function needs a name with underscores, it's possibly a sign that you should break it into multiple functions.
But in your own code, use whatever convension that suits you.
I’m no expert on Julia, but the line you quote is located under the header “Stylistic Conventions” and I would presume that’s basically it.
There is an additional section about naming conventions in the docs under Style Guide
There is a line in there that says:
“Underscores are also used to indicate a combination of concepts”.
So if you decided to use a lot of underscores in your function names, the next programmer to work on your code might think you are “combining concepts”.
What are the syntactical features of current languages that prove problematic for screen readers or braille readers? What symbols and constructs are annoying to hear or feel? To the blind programmers out there, if you were to design a programming language which was easier for other blind people to work with, what would it be like?
Although it is a very interesting question, it is highly a matter of personal preferences and likings, so I'll answer as if you asked me personally.
Note: My working system is Windows, so I'll focus on it. I can write cross-platform apps, of course, but I do that on a Windows machine.
Indentation, White Spaces
All indentation-related things are more or less annoying, especially if the indentation is made with multiple spaces, not tabs (yes yes, I know the whole "holy war" around it!). Python did teach me to indent code properly even in languages that don't require it, but it still hurts me to write proper Python because of these spaces. Why so? The answer is simple: my screen reader tells me the number of spaces, and the actual nesting level is four times less. Each such operation (20 spaces, aha, dividing by 4, it is fifth nesting level) brings some overhead to my mind and makes me spend my inner "CPU" resources that I could free for debugging or other fancy stuff. It is a wee little thing, you'd say, and you'd be right, but this overhead is on each and single line of my (or another person's!) code I must read or debug! This is quite a lot.
Tabs are much better: 5 tabs, fifth nesting level, nice and well. Braille display here would be also a problem because, as you probably know, a Braille display (despite the name) is a single line of text, usually 14 to 40 characters long. I.e., imagine a tiny monitor with one single line of text that you pan (i.e., scroll), and nothing besides that. If 20 chars are spaces, you stay with only 20 chars left for the code. A bit more, if you read in Grade 2 Braille, but I don't know whether it would be appropriate for coding, I mostly use speech for it, except some cases.
Yet more painful are some code styling standards where you have to align code in the line. For instance, this was the case with tests in moment.js. There the expected values and messages should match their line position so, for example, the opening quote would be in column 55 on every line (this is beautiful to see, I admit). I couldn't get my pull request accepted for more than a week until I finally understood what Iskren (thank him for his patience with me!), one of the main developers, was trying to tell me. As you can guess, this would be completely obvious for a sighted person.
Block Endings
A problem adjacent to the previous one: for me personally it is very nifty when I know that a particular code block ends. A right brace (as in C) or the word end (as in Ruby) are good, indentation level change (as in Python) is not: still some overhead on getting knowing that the nesting level has abruptly changed.
IDEs
Sorry to admit it, but there is virtually no comfortable IDE for the blind. The closest to such an IDE is Microsoft Visual Studio, especially the latest version (gods bless Jenny Lay-Flurrie!), Android Studio seems also moving towards accessibility starting with version 2. However, these are not as usable, nifty and comfortable as they are for the sighted users. So, for instance, I use text editors and command-line tools to write, compile and debug my code, as do many blind people around me.
Ballad of the snake_case, or Another Holy War
Yet another thing to blame Python about: camelCase is far more comfortable to deal with then snake_case or even PascalCase. Usually screen readers separate words written in camelCase as if they were separated with spaces, so I get no pain readingThisPartOfSentence.
When you write code, you have to turn your punctuation on, otherwise you'll miss something really tiny and "unimportant", such as a quote, a semicolon or a parenthesis. Then, if your punctuation is on, and you read my_very_cool_descriptive_variable_name, you hear the following: "my underline very underline cool underline.... underline underline underline!!!" (bad language and swears censored). I tried even to replace underlines with sounds (yes, my screen reader gives such an opportunity), but the sounds can't be so well synchronized because of the higher speech rate I use. And it is quite a nightmare when dealing with methods and properties like __proto__ (aha, there are two underscores on both sides, not one, not three - well, got it right, I think!), __repr__ and so on, and so forth. Yes, you might say, I can replace the word "underline" with something really short like "un" (this is also possible), but some overhead is still here, as with white spaces and code nesting.
PascalCase is far better but it implies a bit more concentration, also, since we need to remember putting the first capital letter (oh, I'm too fastidious now, let it be PascalCase, but not those under... oh well, you got it already). This was the reason I gave up with Rust, btw.
Searching for Functions
As I have already told you, IDEs are not good for us, so text editor is our best friend. and then, you need to search for functions and methods, as well as for classes and code blocks. In certain languages (not Python this time), there are no keyword that would start a function (see, for example, C or Java code). Searching for functions in these conditions becomes quite painful if, for example, you do know that you have a logical error somewhere in the third or fourth function in the file, but you don't exactly remember its name, or you skim through someone's code... well, you know, there are lots of reasons to do that. In this particular context, Python is good, C is not.
Multiple Repeating and Alike Characters
This is not a problem per se, but a circumstance that complicates debugging, for example, regular expressions or strongly nested operations like ((((a + ((b * c) - d) ** e) / f) + g) - h. this particular example is really synthetic, but you get what I mean: nested ternary operators (that I love, btw!), conditional blocks, and so on. And regular expressions, again.
The Ideal Language
The closest to the ideal blind-friendly language as for me is the D language. The only drawback it has is absence of the word function except for anonymous functions. PHP and Javascript are also good, but they have tons of other, blind-unrelated drawbacks, unfortunately.
Update about Go
In one of his talks Rob Pike, the main developer of the Go language said that no one likes the code style imposed by the Gofmt utility. Probably, no one — except me! I like it, I love it so much, every file in Go is so concise and good to read, I'm really excited about the language because of that. The only slightly annoying thing for a blind coder is when a function has several pairs of parentheses in its definition, like if it is actually a struct method. the <- channel operator still gives me moments to think about what I'm doing, sending or receiving, but I believe it's a matter of habit.
Update about Visual Studio Code
Believe it or not, when I was writing this answer and the first update to it, I wasn't working as a full-time developer — now I am. So many circumstances went favorably for accessibility and me in particular! Slack, that virtually every business uses, became accessible, and so became Microsoft Visual Studio Code (again, gods bless Jenny and her team!). Now I use it as my primary code editor. Yes, it's not an IDE per se, but it's sufficient for my needs. And yes, I had to rework my punctuation reading: now I have shorter and often artificial names for many punctuation signs.
So, calling from end of January 2021, I definitely recommend Visual Studio Code as the coding editor for blind people and their colleagues. What is even more amazing is that LiveShare, their pair programming service, is also accessible! Yes, it does have some quirks (for now you can't tell what line in the file your colleague is editing if you're blind), but still it's an extremely huge step forward.
While learning QML, I want to learn a good style from the beginning.
However, I already encountered some problems when it comes to naming, and I can't find something like "world-acclaimed" coding conventions, that not only cover the order of your statements, but also some good naming conventions
(as found here: http://doc.qt.io/qt-4.8/qml-best-practices-coding.html).
The problems I find are as follows:
properties, IDs, (model)roles - they can all clash pretty easy, especially as the IDs and roles are present through multiple layers of items.
So are there any good guidelines on how to name your:
properties
roles
IDs
functions
function variables
components
that have proved worthy in the field?
QML already enforces some naming conventions - types must begin with capital letter, properties must begin with lower case letter, etc.
Unfortunately, QML elements come with quite a lot of stuff to them, and it is often the case where you get naming conflicts. In that case the "innermost declaration" seems to take precedence when resolving stuff, that is your own declarations will shadow stock properties, and there is no way to address those anymore, unlike in C++ where you can BaseType::stuff. I have outlined a possible approach in case you need to override and still access "inherited" members here.
If all you need is to avoid clashes - prepending something works very well. The most basic way is to use the underscore as in _something - QML's stuff never begins with an underscore, so there is no danger of clashing. For types, I prepend a character as well, which is also useful to sort/group components in the project tree view, I prepend U_Something - U for UI, C for core, P for prototype and so on. Same old approach that has been used through perpetuity in programming, especially in languages that don't have classes, namespaces and such and the only way to avoid conflicts is to use names such as VK_ERROR_FORMAT_NOT_SUPPORTED quite common in C APIs such as Vulkan.
When working on code from multiple authors, I often encounter the issue of curly-brace preference (same line vs new line). Is it good/bad practice or even a non-issue when it comes to matching the existing style vs using your own preference?
Does the situation change if you are adding new code to a Class vs modifying existing code? Finally, if style should be matched, how far should the match propagate? i.e. the file, the class, subclasses etc.
Example:
if(this)
{
doThat();
}
Vs.
if(this){
doThat();
}
Generally speaking, inconsistently formatted code will be more difficult to read and understand than code formatted in a style other than your own.
When working on an open source project, it is considered polite to match the style in use. For code you won't be sharing, either follow the style or run all the existing code through a reformatter.
It matters a great deal if a lot of code has been checked into a version control system. There will be a lot of noisy change in the history for a mere brace style change. I wouldn't do it for its own sake. You're in Rome....
If you will be sharing this, match his style for consistency. If not, do what you find comfortable. I personally prefer your style.
Try to talk with your coworkers and decide on a consistent style. Once you do that, write all new code in that style and convert old code if necessary. This is an issue specific to the project and the people working on it.
On the rare occasion that you can't come to a consensus, I wouldn't worry too much; there are far too many bugs in the world for people to be spending their time moving braces around. :D
It does not matter (code wise) where you place the curly braces, it is just a matter of preference. More experienced coders tend to put it on the same line, but I like to put it on the next line because it helps me see blocks of code easier. If you wish coding conventions to go as far as curly braces, then consult your team and choose one, but they'll probably laugh lol
There is nothing that irks me more than perusing code and finding numerous mismatched styles sprinkled throughout. If you are going to collaborate with someone on a program, than either explicit or implicit, standards should be used. Something as simple as a curly brace doesn't matter in the least, but when your project gets reviewed by management and you can't even get that one little thing matched up throughout it looks bad. Or if you are working on a personal project with friends and then decide to have others join, the project is going to start off looking unprofessional. I would say when working in a group like this, it is less about personal opinion, than it is about group standards.
I'm writing a parser to parse CSS.
I started by modifying the CSS reference grammar, to use whichever grammar and lexer syntax are supported by the 3rd-party parser generator tool which I'm using.
I think that I've finished coding the grammar: the parser-generator is able now to generate state transition tables for/from my grammar.
The result (the output from the parser-generator) is approximately 116 "rules", which correspond to 116 cases in a switch statement. Examples of these rules/switch statements are:
Stylesheet begins with specifying a charset
Stylesheet begins without specifying a charset:
Stylesheet is empty
Stylesheet begins with whitespace
...etc...
The parser-generator has done all it can for me, and now I'm begining to write (by hand) the various cases of the switch statements, which will build what I think people call an 'abstract syntax tree'.
My question is about how to test this. I think that what I want is a set of CSS files which exercise the various combination and possibilities: e.g. one CSS file which specifies a charset; another file which doesn't specify a charset; etc.
Is there general a way to auto-generate this set of input data, for an arbitrary grammar or set of rules?
Alternatively, is there a set of specifically CSS files, whose purpose is to cover the combination and possibilities allowed by the standard CSS grammar?
Feel free to comment too if I'm going about this all wrong.
At the moment I don't need:
Files to test handling of illegal input (i.e. of files which don't conform to the grammar)
Testing of how various browsers render based on their parsing of CSS
Microsoft made a set of many thousands of CSS tests for IE8 compliance with the CSS spec.
http://samples.msdn.microsoft.com/ietestcenter/css.htm
While they are focused on testing browser compliance, possibly you could adapt them.
There are also the older W3C test suites, which are not as complete, but might serve your purpose:
http://www.w3.org/Style/CSS/Test/
A context free grammar implicitly proposes an infinite set of (parse) trees. Each proposed tree has a set of leaves which make a concrete sentence in the language accepted by that grammar. By exploring the the set of proposed trees (e.g, by expanding each nonterminal according to it possible alternatives), you can generate any arbitrary instance of the language. You can generate a set of tests by walking the tree proposals and making random choices. A more focused approach would be to use iterative deepening search to generate sentences ordered by size. With any interesting grammer, you're likely to get a huge number of instances, but hey, that's what automated testing is for.
What I wouldn't do is generate such sentences from your production grammar, because the sentences you generate will be, by definition, the ones it accepts :-{ What you should do is construct your sentence generator using the reference grammar, to exploit the fact that you what it accepts and what you've implemented might be different.
4 years late for OP but SimonSapin/css-parsing-tests seems like a decent test suite for parsers.