Except that you can't send the diffs to another person, attach them to bug reports, etc.
And some more reasons not to do automatic reformatting:
- formatters can't fix aything non-syntax related, like strange variable naming conventions.
- reformatting makes your environment completely different from everyone else's (including your coworkers and customers). Eg: stack traces you get on one machine are completely different compared to the ones you get.
Having a code convention (and sticking to it) makes everyone's life easier in the long run.
Use indentation, not braces: The braces are probably going to be pushed off the bottom of the window for long functions/methods whatever, and your brace style just make this problem worse.
"The solution is to use a pretty printer program that is sophisticated enough to understand and generate the source repository form, and automatically reformat to the tastes of most developers."
Yeah, that works fine except that when translating your crack-induced style to the normal form and back again screws up revision control diffs, thereby making them completely useless.
Also, your little rant about documentation basically boils down limitations in tools. Javadoc since 1.4 (1.3, maybe) automatically provids docs for methods you've overridden but not supplied documentation comments for in the source.
"The rules by which I like to code are (a) read anything formatted reasonably; (b) format new code I create any damn way I please (within reason -- I have to maintain it too); (c) defer to the style already present when maintaining legacy code."
a) correct b) god, I'd hate to work with a selfish arsehole like you c) correct
"For all your code-nazi bluster, you're screwed when you decide to leverage some open source code that uses a different style and there's the possibility you might contribute your changes back to the official code base"
What, you're not suggesting copying and pasting the code in are you? What decade do you live in, the _70's_? Up here in the 00's, we have this thing called code reuse. Wonderful things like OO and libraries and oh my! In cases like this, we apply rule (c) that you mentioned above.
Is the a way to mod a story as a troll? This one sure as hell is. Look, I don't know exactly what license PHP uses, but unless it it some fruitcake that the PHP people can retroactively revoke for all versions, who cares if Zend is partnering with Sun?
PHP is getting more exposure, features and deployments? And you're complaining? Christ! If you don't like 5, keep using 4. If you don't like writing OO, write your same old procedural code!
And what if it is owned by Sun? Exactly what is the problem with that when it is effectively owned by Zend right now?
It sounds like some anti-Java zealot got their nose out of wack because a few Java-like features are in 5, or maybe you have some personal axe to grind about Zend, Sun or MySQL Inc for some reason.
Well, two years is a *long* time for browser development (except for IE) In that time frame you'll see at least one new version of Safari and Opera, probably three or four releases of Mozilla and so on. By using standardised features that are not commonly implemented now, people using newer broswers will get a *better* experience in the future. This has the added bonus of extending the life of your websites. Instead of getting two years from it, you might get three or four.
Also, not everyone can afford to (or want to) re-haul their website every few years. My website was terrible unless you used Moz a few years ago. These days it is great in a wide variety of browsers. I know of intranet web applications that have been in use for at least four years. If they had been written using all of the HTML and CSS features that were not widely implemented back then, they would be much better to use today than they currently are.
"BUT the issue is that most of the world DOESN'T USE MOZILLA, they use IE. Will you make a website that looks wrong but is still works with w3c standards... But that 95% of the world will not see properly!?!?!"
Yep, but think about the future. The trend is that browsers are becoming more standards compliant, and more people are switching away from IE. So in the long run by making sites that work better with IE than a standards-based browser, you're going to loose out.
By providing a better experience for people using standards-based browsers, your web sites will look better as time goes on, instead of looking worse./mike
i) prevents fair use, allows instant censorship ii) software patents, locking competitors out of hardware (TCPA) iii) any *thing* would be better than Bush - my right bollock for example
Using Linux is one way to acheive freedom. Remove that and you've got one way less to be free.
How long until you have no freedom left?/Mike
Re:Political commentary at the Key Bridge in DC
on
Reverse Graffiti
·
· Score: 0, Offtopic
Err, no. Saddam ignoring the UN resolutions of just one of many excuses Bush used to jusify the invasion.
Not that I agree 100% with that statement by the parent, but you're sprouting as much gibberish, if not more./me hits both of you with a cluestick
VML was a submission (by MS, HP, et all) to the W3C. They werre basically saying "we have this technology which you should make into a standard". VML never was and never will be anything other than Yet Another Proprietary Image Format.
Mozilla doesn't support VML because no one uses it and hence no one is iterested in implementing it. It may also be IP encumbered.
If it's impossible to implement something cross-platform (like clieny-side.NET integration) then you can bet m.o won't be interested in doing it. That's not stopping you from doing it yourself as a plugin or as an XPCOM component, but why bother? What do you get from it?
The Gnome implementation of the Accessibility Toolkit uses Bonobo, so as long as your favourite language has Gnome bindings which supports Bonobo, you're set.
It's here today, and it works. I was at the talk at LCA this year. Write a Python script, add a launcher for it on your panel/desktop, and away you go!
Slashdot Mirror
No, you are translating for working purposes. As I've pointed out elsehwere, this sucks.
consider:
foo() {
some lone line();
bar()
}
vs:
foo()
{
some
long
line();
bar();
}
On what lines does bar() appear in both?
Except that you can't send the diffs to another person, attach them to bug reports, etc.
And some more reasons not to do automatic reformatting:
- formatters can't fix aything non-syntax related, like strange variable naming conventions.
- reformatting makes your environment completely different from everyone else's (including your coworkers and customers). Eg: stack traces you get on one machine are completely different compared to the ones you get.
Having a code convention (and sticking to it) makes everyone's life easier in the long run.
The second, by far.
Use indentation, not braces: The braces are probably going to be pushed off the bottom of the window for long functions/methods whatever, and your brace style just make this problem worse.
Because when you format back and forth, you invariably break diffs generated by revision control software.
Stuff like:
foo () {
some really long line
}
becomes:
foo ()
{
some
really
long
line
}
becomes:
foo() {
some really
long line
}
or whatever.
It's a pain in the arse.
"The solution is to use a pretty printer program that is sophisticated enough to understand and generate the source repository form, and automatically reformat to the tastes of most developers."
Yeah, that works fine except that when translating your crack-induced style to the normal form and back again screws up revision control diffs, thereby making them completely useless.
Also, your little rant about documentation basically boils down limitations in tools. Javadoc since 1.4 (1.3, maybe) automatically provids docs for methods you've overridden but not supplied documentation comments for in the source.
"The rules by which I like to code are (a) read anything formatted reasonably; (b) format new code I create any damn way I please (within reason -- I have to maintain it too); (c) defer to the style already present when maintaining legacy code."
a) correct
b) god, I'd hate to work with a selfish arsehole like you
c) correct
"For all your code-nazi bluster, you're screwed when you decide to leverage some open source code that uses a different style and there's the possibility you might contribute your changes back to the official code base"
What, you're not suggesting copying and pasting the code in are you? What decade do you live in, the _70's_? Up here in the 00's, we have this thing called code reuse. Wonderful things like OO and libraries and oh my! In cases like this, we apply rule (c) that you mentioned above.
Sounds like someone had a bad day at the office.
Is the a way to mod a story as a troll? This one sure as hell is. Look, I don't know exactly what license PHP uses, but unless it it some fruitcake that the PHP people can retroactively revoke for all versions, who cares if Zend is partnering with Sun?
PHP is getting more exposure, features and deployments? And you're complaining? Christ! If you don't like 5, keep using 4. If you don't like writing OO, write your same old procedural code!
And what if it is owned by Sun? Exactly what is the problem with that when it is effectively owned by Zend right now?
It sounds like some anti-Java zealot got their nose out of wack because a few Java-like features are in 5, or maybe you have some personal axe to grind about Zend, Sun or MySQL Inc for some reason.
Stop whinging and pull your head in, Ian Felton.
Also, not everyone can afford to (or want to) re-haul their website every few years. My website was terrible unless you used Moz a few years ago. These days it is great in a wide variety of browsers. I know of intranet web applications that have been in use for at least four years. If they had been written using all of the HTML and CSS features that were not widely implemented back then, they would be much better to use today than they currently are.
/mike
"BUT the issue is that most of the world DOESN'T USE MOZILLA, they use IE. Will you make a website that looks wrong but is still works with w3c standards... But that 95% of the world will not see properly!?!?!"
/mike
Yep, but think about the future. The trend is that browsers are becoming more standards compliant, and more people are switching away from IE. So in the long run by making sites that work better with IE than a standards-based browser, you're going to loose out.
By providing a better experience for people using standards-based browsers, your web sites will look better as time goes on, instead of looking worse.
/mike
This is already how it works. Deisgners who care use the right DOCTYPE, which triggers sandards-compliant rendering in modern browsers.
/mike
Designers who don't care don't use a DOCTYPE and get rendered using a compatibility mode.
This is how Moz, IE6 and Safari work (at least).
Troll!?! How was this a troll?!
Well, point (iii) may have been trollish, but the rest was bloody well insightful.
mod == crack
i) prevents fair use, allows instant censorship
/Mike
ii) software patents, locking competitors out of hardware (TCPA)
iii) any *thing* would be better than Bush - my right bollock for example
Using Linux is one way to acheive freedom. Remove that and you've got one way less to be free.
How long until you have no freedom left?
Err, no. Saddam ignoring the UN resolutions of just one of many excuses Bush used to jusify the invasion.
/me hits both of you with a cluestick
Not that I agree 100% with that statement by the parent, but you're sprouting as much gibberish, if not more.
1 - Ask Slashdot ...
2 -
3 - Profit!
Har-har!
Err, no.
.NET integration) then you can bet m.o won't be interested in doing it. That's not stopping you from doing it yourself as a plugin or as an XPCOM component, but why bother? What do you get from it?
VML was a submission (by MS, HP, et all) to the W3C. They werre basically saying "we have this technology which you should make into a standard". VML never was and never will be anything other than Yet Another Proprietary Image Format.
Mozilla doesn't support VML because no one uses it and hence no one is iterested in implementing it. It may also be IP encumbered.
If it's impossible to implement something cross-platform (like clieny-side
you = smell
You = clueless.
Yeah! You sure told *him*!
Which is of course *exactly* what is wrong with KDE. You only need one completion method that works well.
"Well *my* kettle boils water in twelve different ways!"
-mike
Sure.
The Gnome implementation of the Accessibility Toolkit uses Bonobo, so as long as your favourite language has Gnome bindings which supports Bonobo, you're set.
-mike
NP! :)
Remote Control and Scripting of Gnome Applications with Python. It should also work for KDE and Java apps once they get their act together.
It's here today, and it works. I was at the talk at LCA this year. Write a Python script, add a launcher for it on your panel/desktop, and away you go!
-mike
And you know, you can thank Apple for that. The general modus operandi for the x86 industry is:
1) See what Apple does
2) Copy it
3) Profit!
The examples are endless: WIMP user interface, funky cases, USB for mouse and keyboard, firewire, no floppy drives, etc, etc, etc.
Thank god for that company. If it wasn't for them, we'd all still be using ISA cards, PS/2 connectors, and D-sub 15's.!
-mike (who's never owned an Apple in his life)