91–100 of 118 posts
It would be awesome if someone built a Bootstrap version converter. I'm currently using v2.2.2, and I simply don't really have the time to go through all the code to get it upgraded to the extent of making sure nothing breaks. Does anyone know the best way to do things like this, if a converter doesn't exist? It would be nice if the docs still had old versions, sort of like WordPress or PHP docs do, where you can see…
> Renamed all of the variables to use dashes instead of camelCase. I absolutely detest camelCase. It ranks down there with good-old Hungarian notation. So, I am now wondering, why this change? Are people finally coming to their senses?
I'll work with either, but kebab-case(or snake-case with dashes if you prefer) is a lot more readable in HTML source for me. Also, all their CSS classes were kebab-case anyway, so it makes sense that they'd change their variables to match. It's a nice move towards consistency.
It would be awesome if someone built a Bootstrap version converter. I'm currently using v2.2.2, and I simply don't really have the time to go through all the code to get it upgraded to the extent of making sure nothing breaks. Does anyone know the best way to do things like this, if a converter doesn't exist? It would be nice if the docs still had old versions, sort of like WordPress or PHP docs do, where you can see…
The best solution I've been able to cook up is adapting their changelog into a step-by step tutorial for developers to use when upgrading, though I'd love to hear any suggestions on improving that process!
Earlier quoted context omitted.
just-testing-this JustTestingThis Hmm. I think it only matters to me that the author picks one and stays with it. But that means that all libraries he uses has to use the same one. Which is why languages tend to prefer one over the other. e.g. Java using CaMeLcAsE To have them mixed in one code base would be like a micro context switch.
Ah, see, you would have received an error when running this code! It's "justTestingThis" not "JustTestingThis" if we are talking camel case. So yeah, camel case and case sensitivity add unnecessary fragility to programming. Which is the reason I don't like the fad. You accidentally made my case.
It's useful.
Earlier quoted context omitted.
"I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case?" No, there isn't. It's one of those typical things that novice programmers fret about. Consistency within a code base is much more important than which style is used exactly. Having the style be a compile parameter would make sense to me, not switching from one to the other.
> It's one of those typical things that novice programmers fret about. I think you might be generalizing a little too far here. I've been programming for over thirty years in more languages than I care to remember. Every so often a meme of some sort raises to the surface and the sheep jump on it. Hungarian notation was probably one of the ugliest of all. Case sensitivity is another. And, case sensitivity added to cam…
As I can't find any data, I've asked on programmers.stackexchange.com. http://programmers.stackexchange.com/questions/186407/are-th...
Earlier quoted context omitted.
I don't ever recall saying that, but if I did, I'm happy to have been wrong. Super stoked about the direction we're going.
I am not sure what "mobile first" means, could you please explain what that means for the end-developers? The only thing to that effect I see right now is that responsive less files will no longer be separate from the core. That will probably mean that I will be forced to support mobile platforms. Is there more to it? (Aside, wishing someone would take a deeper look at https://github.com/twitter/bootstrap/issues/4935…
It would be awesome if someone built a Bootstrap version converter. I'm currently using v2.2.2, and I simply don't really have the time to go through all the code to get it upgraded to the extent of making sure nothing breaks. Does anyone know the best way to do things like this, if a converter doesn't exist? It would be nice if the docs still had old versions, sort of like WordPress or PHP docs do, where you can see…
We were targeting to have it out more for 2.x to 3.0 as that will be a bigger jump.
Earlier quoted context omitted.
> Consistency within a code base is much more important than which style is used exactly. I know this is a commonly held belief, and I held it too for a short while. But then, I was managing a project that ran on both Linux (lower_case_name libraries), Windows (CapitalizeEachWord), had components in Python (ClassesAreLikeThis but variables_like_this), Java (camelCaseIsAnAbomination) and even some VB6 (don't even reme…
Well within several modules of the same project, I guess it's inevitable, and not that problematic, especially not between several languages; but seeing (at the top of one function) int my_counter; char hostName[256]; double LIFESPAN; doesn't make for pleasant reading, I'm sure you agree.
Our main codebase used unix_conventional_names. Then, a GUI (FLTK, C++) was added, with classes like Fl_DoubleWindow; Every GUI part now had two conventions.
Then, it turned out that the abstractions FLTK gave on Windows needed a small nudge. So we added some Windows-specific stuff; that module had calls like FLTK Fl_RadioButton, Win32's TrackMouse, our main code's "user_action_t".
Then we added needed to add Python scripting (implementing a native Python module in C) - and since the most maintainable way to do that was to have the C names and Python names correspond, there's a module that also had Python convention names in it. Lather, rinse, repeat with JNI.
So, I would guess ~ 70% of the files ended up being "uniform convention" (with one convention, depending on source code language), and 30% had mixed conventions of up to 4 conventions.
And it didn't make anything a little bit unreadable. It's no more distracting than changing fonts in a document every paragraph (and occasionally in the middle of a paragraph) between several readable standard fonts (arial, courier, consolas, ...). It looks weird and bothering for the first few days, but is not actually distracting or hampering in any way.
And if anyone is going to reply "but new people who come into the codebase will be confused" - that codebase was moving millions of dollars per day, and was nontrivial enough that I wouldn't allow anyone to commit a change on their first week, often their first month, without two other people reviewing it (experienced people got only one person to review their code).
By the time anyone knew the code well enough to make a change, they weren't bothered by the multiple conventions either.
> doesn't make for pleasant reading, I'm sure you agree.
only lifespan, the upper case implying constantness when it isn't, bothers me. Other than that - pleasant as day.
Earlier quoted context omitted.
Why on earth would that mean you'd be forced to support mobile platforms?
That should have read "forced to deal with mobile platforms". I currently have scenarios where I want the same version on the desktop and mobile. That's trivial because I simply don't include the responsive CSS file. In 3.0 the media queries are part of the core. So I can't just leave the responsive CSS out. Further, it's mobile-first so things like the navbar would be collapsed by default on a mobile device. I would…
It would be awesome if someone built a Bootstrap version converter. I'm currently using v2.2.2, and I simply don't really have the time to go through all the code to get it upgraded to the extent of making sure nothing breaks. Does anyone know the best way to do things like this, if a converter doesn't exist? It would be nice if the docs still had old versions, sort of like WordPress or PHP docs do, where you can see…
Note I think this applies primarily to the CSS part of Bootstrap which I consider to be more of a template than a library or framework; the JavaScript plugins are always pretty painless to upgrade.