It looks interesting, that's for certain. I don't know that I would want to use it all the time yet, at least because I couldn't drag-and-drop a file between platters.
For those who are curious what it looks like, I took a couple of screenshots. At the risk of slashdotting my school's server, they are here:
just so it will take up more room in their briefcase/backback
That's not the only reason... some people will actually want their monitor to have that pixel depth, but cause less eyestrain trying to squint at the smaller display.
I hate to admit it, but as I get older, I'll probably want the same sort of things myself.
I helped develop our coding standard at work, although it is still somewhat a work in progress. Bear in mind that this is all for C/C++, but a lot of it may carry over into Java.
I don't think you need to be reminded of the reasons for having a coding style standard, but in case anyone questions it, it undoubtly increases readability of people's code, and reduces the time needed to understand other people's code. We have also found that we are slightly better organized in how we produce code when we follow these guidelines.
Some suggested things to think about:
Naming Conventions? Be sure to have all functions named the same way, regarding capitals, underscores, and that sort of thing. The same with variables, macros, and whatever else you can think of.
For example, you might say all begining capitals for functions, such as "void OnOKButtonClicked()", first lower case then all starting caps for variables, such as "fltNewGradePercentage", and all caps for macros, such as "STANDARDSIZE".
Where do braces go? Some people prefer ending the line with an open brace, then indenting the next line. Others like having the open/close braces on lines by themselves, indented with the rest. Still others like the latter, but without indenting them. Find one that everyone currently there can agree on, and enforce it, so that everyone can get used to seeing the braces one way, which improves debugging and code reviews, among other things, when you don't have to be getting used to ignoring a different brace style than what you are used to.
How are variable names constructed? Some people have different prefixes/suffixes to signify things about the variables, such as the fact that they are global, or class members, and also what type of variable they are - ints, chars, pointers, etc.
For example, at work, we use three-to-six letter prefixes to designate the type of the variable - intFiles is an int, chrpCurrent is a character pointer, etc.
Indentation Standards? Some people don't believe this should be important, but it depends on how similar your development environments are. If you all use the same IDE, then this is unimportant. If, however, you develop on Unix/Linux with a wide range of editors (vim, emacs, kwrite, etc), then indentation needs to be standardized to have the display readable on each of these. Also, do you allow tabs or not?
Comments? Yes, do use them. But, where are they required? The easiest place to require them is in the header for classes, for the public member functions. They should at least explain what the function does, what the arguments are that it takes, and what it returns. (I personally think that all functions, not just the public ones, need these. But perhaps that's just due to the fact that I can't interpret "int GetPtHitOn3dMseClk(int x, int y, int z)" very easily.)
Spaces? Spaces need to be determined - as in, where are they absolutely required. At work, we use spaces, at a minimum, between math operators and after commas in a parameter list. Other places may also be useful.
I'm sure that there are other things to think about, which will be suggested, but these are places to start when considering a standard.
Note: I'm not involved in CFD as much as some... I just work at a company doing CFD consulting in the U.S. for specific applications.
That said, it appears to me that the applications available for more traditional Unix boxes and cheap Linux boxes are about the same. Such being the case, I would certainly go with a Linux box, just for the price factor... it seems as if you can get more raw computing power with Linux on a mid-range PC than on other platforms. Of course, this is just from anecdotal experience from within my company, but why else would you be asking/. in the first place?
> After installing bash, XFree86 (XDarwin), GTK+...
You got GTK+ installed? How did you manage that? I admit that I'm not an expert in porting code, but I gave up after trying off and on for a few days, which was a real shame, because that's the toolkit that I'm used to using.
Solution for those cracks?
on
Dual G4 Mac Cube
·
· Score: 4, Funny
Would this be a potential solution for the cracks that were supposed to be in the Cube cases? Get it just warm enough to meld them together again...
When the actual technology of self-replicating programs hit the web, a type of the programs was named "worm", from the name John Brunner used for the software in his novel Shockwave Rider.
My company went through this...
on
GTK-- vs. QT
·
· Score: 5, Informative
About a year ago, the company I work for went through this. (This was before I worked for them.) The company debated the merits of Gtk-- and Qt. The basic conclusions were that Qt would (or at least, should) have the better support and documentation, and lack minor irregularities. However, when it was all computed, the deciding factor was the licensing fees. Since our software would be quasi-commercial (we are a consulting company, but for a fee, we provide companies with portions of our software as well) we would have to pay the licensing fee for Qt. This was a lot more than was thought our ~6 person (at the time) company could afford, so we went with Gtk-- pretty much only for that reason.
Now that we have been using Gtk--, we have relatively few regrets. The documentation was poor, for a time, but they have semi-recently improved the documentation, and it is quite workable. There are some small things that you would think would be done differently, but overall they are very minor and easy to live with.
Since we aren't concerned (yet) with porting our software, that wasn't much of an issue. Of course, your situation may be different there.
Finally, echoing what other people have said here, Gtk-- can be quite low level at times. I would recommend that if you decide upon Gtk--, you do what our company has done. We created our own set of libraries that provide standard looks to things with minimal hassle, derived from the Gtk-- classes. An example of this would be windows. We have our own window class that sets up standard options that Gtk-- allows to vary considerably. (Additionally, it automatically checks for certain keystrokes, like the F1 key, and signals that fact.) Making a button class would be similar, so all of your buttons are approximately the same size, have the same shading, etc. We were late in figuring this out, but it has greatly simplified our code and made our program look much more consistent.
This reminds me of a signature a guy used at a company I used to work for. (The company won't be mentioned, but let's just say there are jokes out about the returns on their stock compared to collecting the deposit on beer bottles.)
Anyway, the signature:
You can have it: Correct, Cheap, Now. Pick any two.
Slashdot Mirror
It looks interesting, that's for certain. I don't know that I would want to use it all the time yet, at least because I couldn't drag-and-drop a file between platters.
For those who are curious what it looks like, I took a couple of screenshots. At the risk of slashdotting my school's server, they are here:
Platters View.
A welcome return of Labels.
The Get Info window.
just so it will take up more room in their briefcase/backback
That's not the only reason... some people will actually want their monitor to have that pixel depth, but cause less eyestrain trying to squint at the smaller display.
I hate to admit it, but as I get older, I'll probably want the same sort of things myself.
I don't think you need to be reminded of the reasons for having a coding style standard, but in case anyone questions it, it undoubtly increases readability of people's code, and reduces the time needed to understand other people's code. We have also found that we are slightly better organized in how we produce code when we follow these guidelines.
Some suggested things to think about:
For example, you might say all begining capitals for functions, such as "void OnOKButtonClicked()", first lower case then all starting caps for variables, such as "fltNewGradePercentage", and all caps for macros, such as "STANDARDSIZE".
For example, at work, we use three-to-six letter prefixes to designate the type of the variable - intFiles is an int, chrpCurrent is a character pointer, etc.
I'm sure that there are other things to think about, which will be suggested, but these are places to start when considering a standard.
Note: I'm not involved in CFD as much as some... I just work at a company doing CFD consulting in the U.S. for specific applications.
/. in the first place?
That said, it appears to me that the applications available for more traditional Unix boxes and cheap Linux boxes are about the same. Such being the case, I would certainly go with a Linux box, just for the price factor... it seems as if you can get more raw computing power with Linux on a mid-range PC than on other platforms. Of course, this is just from anecdotal experience from within my company, but why else would you be asking
> After installing bash, XFree86 (XDarwin), GTK+...
You got GTK+ installed? How did you manage that? I admit that I'm not an expert in porting code, but I gave up after trying off and on for a few days, which was a real shame, because that's the toolkit that I'm used to using.
Would this be a potential solution for the cracks that were supposed to be in the Cube cases? Get it just warm enough to meld them together again...
When the actual technology of self-replicating programs hit the web, a type of the programs was named "worm", from the name John Brunner used for the software in his novel Shockwave Rider.
Now that we have been using Gtk--, we have relatively few regrets. The documentation was poor, for a time, but they have semi-recently improved the documentation, and it is quite workable. There are some small things that you would think would be done differently, but overall they are very minor and easy to live with.
Since we aren't concerned (yet) with porting our software, that wasn't much of an issue. Of course, your situation may be different there.
Finally, echoing what other people have said here, Gtk-- can be quite low level at times. I would recommend that if you decide upon Gtk--, you do what our company has done. We created our own set of libraries that provide standard looks to things with minimal hassle, derived from the Gtk-- classes. An example of this would be windows. We have our own window class that sets up standard options that Gtk-- allows to vary considerably. (Additionally, it automatically checks for certain keystrokes, like the F1 key, and signals that fact.) Making a button class would be similar, so all of your buttons are approximately the same size, have the same shading, etc. We were late in figuring this out, but it has greatly simplified our code and made our program look much more consistent.
This reminds me of a signature a guy used at a company I used to work for. (The company won't be mentioned, but let's just say there are jokes out about the returns on their stock compared to collecting the deposit on beer bottles.)
Anyway, the signature:
You can have it: Correct, Cheap, Now. Pick any two.