|
I took a look. They both mix structural and stylistic parts at some levels, but separate at others.
|
|
|
|
|
Nothing like consistency, right? 
For a personal answer to your question I would group your CSS semantically.
Define groups of user elements (containers, sidebars, banners, text areas, lists etc). I wouldn't use adjectives (big, small etc) so instead of bigBox I'd use "box". Your 'bigBox' may evolve one day into being smaller than other boxes.
You could then have a set of placement classes: "box side", "box main-content", "box callout".
Then a set of use-case classes: "box callout error"
Finally, you may wish to have style classes for theming, but never name the class based on their internal style. Instead of "lightblue" it could be "main-theme", or "sub-theme". This allows you to change your colours in one place and have the class names still make sense.
As a postscript there's the cheat classes we all use. "bold", "small" etc. We want the text to stand out boldly, and we can't think of a synonym for bold that won't be confusing, so we do class="label bold" instead of class="label" style="font-weight:bold">. Because we may want "bold" to mean "slightly bigger" or "with lasers flying out of it". I'm still waiting for W3C to ratify the text-decoration: lasers value. Still waiting...
cheers
Chris Maunder
|
|
|
|
|
I'll vote for lasers! 
Your naming suggestions make sense. Thanks.
|
|
|
|
|
I have been separating my CSS documents based upon it's function since around 2004. The reason I started doing it was to easily find what I needed and so classes didn't conflict with one another. I have not used Bootstrap or W3 yet. Typically, I have a structure.css (container), a main.css for the main content including HTML controls, grid, calendar, nav, foot, and head.css. Then I'll import another for a certain page if needed.
So the way you're using skelton.css layout and skins.css for coloring is the way I do it. I cannot say that is best practice with Bootstrap and others out there, but I have more control and I know what I code. And since I know what I code, it is easier to modify, since I don't have to learn anyone else's framework.
|
|
|
|
|
Cool. Yeah, the conflicts is was what I was thinking about. Also side effects. If I keep things that change the box layout separate from those that don't, I know I can use any of the second anywhere and the layout the users sees won't be impacted.
|
|
|
|
|
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name].
But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
|
|
|
|
|
No idea from where this comes, but I also prefer char* c before char *c.
My only Argument:
In case you have a e.g. a method with an argument you don't use, something like
void Method(Object* Sender)
my Compiler shows a warning.
To avoid the warning I Need to
void Method(Object* /Sender/)
or
void Method(Object* )
that's why for me char* c is more intuitive.
On the other Hand variable declaration....
char *a, *b;
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I also prefer char* c as char* is a type, in this case a pointer to a char.
Everyone has a photographic memory; some just don't have film. Steven Wright
|
|
|
|
|
Goes back to K&R, they invented the thing and people followed their style.
also in C you cant declare arrays that way:
char c[];
char[] d;
Tis the style of this language, inasmuch to continue that style far more logical to write */
char *e;
1. and so "char* c" is stylistically wrong in both C & C++. (And older compilers will correctly flag that as an error.)
2. In C "char *" is not a type, it's a pointer to a type. Yup, pointers are not types, they are pointers.
... cats, dogs and cows are types of animal, beef is not an animal but it does 'refer' to one
Signature ready for installation. Please Reboot now.
|
|
|
|
|
I would say "*" is a type modifier 
[Edit]
Quote: In C "char *" is not a type
Really? Ok I don't know C, but I think this is also allowed in C
typedef char@ theCharPointerType;
@ instead of *, because * seems to be a Problem in cp
And if the above is ok in C, how can you state that a pointer to char is not a type?
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
cant be a type modifier either,
char *c --> * means pointer, "char" is is the default 'pointed to' modifier for that declaration.
In the language definition it's valid to cast a * to address any [other] type. If the type was considered "char*" or in fact if "char" had anything to do with 'the type' then casting pointers to address other type would become wrong.
hence:
char* c" /* is wrong, "char*" is NOT the type because there is no such thing, it's wrong, plain wrong! */
char *c /* is the proper form */
Signature ready for installation. Please Reboot now.
|
|
|
|
|
Can be, it is anyway a more philosophical Thing. In case char* is plain wrong it should not be allowed to do this: typedef char* myCharPtr;
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Lopatir is correct. The way to read the declaration
char *c
is: c (the name of the variable)
is a pointer (the * prefix)
to a character (the type)
where the pointer property actually belongs to the variable, not the type.
Having said that I always write:
char* c
|
|
|
|
|
How the hell you can break such a rule? Please refracte (does this word really exists?) all your source code ...please!!! 
[Edit]
Btw, I don't think Lopidar is right. Started with Modula and read a lot from "Niklaus Wirth" theories, also I did a lot of Compiler implementations
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
0x01AA wrote: Please refracte
The correct word would be "refactor". But at my age I may not have enough time to get it all done. 
|
|
|
|
|
So I Need to write: Do refactor your code?
Quote: But at my age I may not have enough time to get it all done
Stop thinking like this!! You have all the time
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
(Just a thought)
"*" works like a "modifier" (in this case); so there "should" be a space ? (e.g. char * e);
But does it then become an "operator" ?
While "_e" is a valid name; as a name, "*e" is NOT valid. (What would a "cross-reference" listing say about "names" and "type").
If we keep the same "characters", the one that feels "more satisfying" (to me) is:
*char e;
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 29-May-18 13:11pm.
|
|
|
|
|
char *c was the old K&R way.
Yes char* c looks better.
modified 27-May-18 15:17pm.
|
|
|
|
|
I prefer "char* c". Long ago I used the other form but an article I read long ago convinced me that the 'type' should be emphasized as different from the variable.
|
|
|
|
|
how do you do: "char c[]" ?? "char[] c" wont compile, so that "type/name" logic is already broken for C/C++.
The article you read was written by someone that either referred to a different programming language, or doesn't understand the C/C++ language definitions; char* is not a type in C/C++.
For real fun, have you considered "char *c[]" ...
writing that the wrong way as "char* c[]" obviously looks, reads and is just plain wrong because that would read as an "array of pointers" when what I wanted was a "pointer to an array."
Personal style is OK, but justifying it as proper with a mistake isn't.
In short: if you prefer the look of "char* c" carry on, just remember it's a pointer, not a type.
Signature ready for installation. Please Reboot now.
|
|
|
|
|
Lopatir wrote: The article you read was written by someone that either referred to a different programming language, or doesn't understand the C/C++ language definitions; char* is not a type in C/C++.
Far as I can recall it was a columnist in the C++ Programmers Journal. I suspect that they did in fact have a passing familiarity with the language. And since at least two columnists in that magazine participated in the C++ ANSI committee I suspect that their opinion on that subject of C++ would have carried more weight than any other random developer. They provided a rational for why that form was more appropriate which, far as I can recall, was not grounded solely in the semantics in the language but more in common usage of type specifiers. But I could certainly be mistaken about what they actually said.
Not to mention of course "The Annotated C++ Reference Manual" written by Ellis and Stroustrup which in section 4.7 has the following code examples.
void f(char* cptr, void* vptr)
...
int* p1 =
...
char* cptr;
int* iptr;
void* vptr;
So seems like the creator of the language prefers that form as well.
My original usage was grounded in the form you are championing but that was based on K&R. I found the article I read persuasive enough that I started using the other form.
|
|
|
|
|
To remind users that
char* a , b
may not do what they intend.
|
|
|
|
|
|
Which is why I never use comma separated variable declarations.
char* a , b, c[12], *d[5];
char* a;
char b;
char c[12];
char* d[5];
www.pointwise.com
|
|
|
|
|
Nor do I. I'm of the opinion that doing so should at least raise a warning.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
