|
brahmma wrote: Truly! Only rogues write code in that style
Oh, you have no idea. Some people thinks this is part of the coding guidelines... which of course it's not.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Some people thinks this is part of the coding guidelines... which of course it's not.
How could you ever know?
You certainly don't have time to read those fascist pamphlets, do you?
Failure is not an option - it's built right in.
|
|
|
|
|
jhwurmbach wrote: You certainly don't have time to read those fascist pamphlets, do you?
Oh, but I have to, even though I don't have the time.
It's considered a prerequiste for the assignment and quite seriously this is how it should be.
My problem is fellow programmers that create or believe in myths about coding guidelines that aren't true and refuse to re-read the guidelines.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Oh, but I have to, even though I don't have the time.
It's considered a prerequiste for the assignment and quite seriously this is how it should be.
In my eyes, all those typing-regulations are constantly getting in your way of doing your job.
Any reasonably experienced programmer has a coding convention which is at least readable by other programmers.
There is no need to have the business-guys define processes for indenting or
writing a for-loop.
Failure is not an option - it's built right in.
|
|
|
|
|
In the end, as long as the compiler is happy, that's all that matters. Each person will say that their style is easiest for them to read and understand. Who are we to argue that? How could you argue with a guy that swears up and down that this makes total sense to him:
int main(int,char*){int x;for(x=0;x<10;x++){printf("%d\n",x);int y=x+1;}return 0;}
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: In the end, as long as the compiler is happy, that's all that matters.
If that were all, there would be no need for any coding style.
But there is.
Im am not arguing for no style. I am arguing for a reasonable style-guide. 10 Rules would be enough.
But all coding style documents I know have more than 10 pages!
To me, this looks like idle-looping of management-turned programmers.
Failure is not an option - it's built right in.
|
|
|
|
|
I agree with both you and David.
Yes, there is a need for a coding guideline.
Yes, of course everyone understands code formatted as if they wrote it themselves better.
In my opinion the guideline should help the developer to write more efficient code and less error prone without making it hard for him/her to read his/her own code.
I consider writing good, working, readable and understandable code an art.
A rigorous coding guideline that prohibits me from writing such code becomes an obstacle to me and affects me negatively. E.g the guidelines I must adhere to for the time being is about 210 pages!
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: E.g the guidelines I must adhere to for the time being is about 210 pages!
By chance is your company/department looking to achieve some ISO or SEI compliance?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: By chance is your company/department looking to achieve some ISO or SEI compliance?
I think "they" already got that. Don't know really since I'm here at consultancy basis.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: I consider writing good, working, readable and understandable code an art.
I, and most others here will, agree wholeheartedly.
But todays managers try to form programming into an industry of putting together standarized pieces.
Roger Stoltz wrote: E.g the guidelines I must adhere to for the time being is about 210 pages!
Wow! I would need weeksto read me through that much of paper!
Our guidelines here are 43 pages, and most are only suggestions (with the state "PREFFERED"), and mostly repeating basic "good practice" stuff. (Like "Number 41: Catch more derived exeptions first").
Failure is not an option - it's built right in.
|
|
|
|
|
jhwurmbach wrote: But todays managers try to form programming into an industry of putting together standarized pieces.
Very true.
However, the thought is good from the beginning. But when those pieces don't really fit together or are badly implemented and actually would require a rewrite, nobody wants to hear about it of course.
At that point there's no pride in the work any longer and one has become a code monkey.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
That's because they are paid to the number of lines of code
|
|
|
|
|
Cedric Moonen wrote: That's because they are paid to the number of lines of code
I heard about how authors get paid by the word in US.
But this requires the code to be submitted using GPL (GNU Publish License).
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
hey, sometimes, it's more readable to write so if the function get tons of parameter.
I prefer seeing my parameters on a single screen rather than having to scroll far right...
|
|
|
|
|
toxcct wrote: sometimes, it's more readable to write so if the function get tons of parameter.
True, but at least do something a little more readable:
nResult = GetResult(Param1,
Param2,
Param3,
...);
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
yes, that's exactly how i used to code
|
|
|
|
|
toxcct wrote: I prefer seeing my parameters on a single screen rather than having to scroll far right...
Agreed!
However, the idea that a code line should not exceed 80 chars comes from a time when we had terminals that were 80x72 tokens.
I prioritize the flow of the code; if I understand the flow I know how the function call should be made and if the parameters are correct.
The sample I showed is confusingly similar to common indentation and hence it's a good candidate for giving my brain the hick-ups.
Read this[^] for other candidates of Roger-brain-hick-ups.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: However, the idea that a code line should not exceed 80 chars comes from a time when we had terminals that were 80x72 tokens.
What terminal used an 80x72 resolution? In DOS it was normally 80x25 unless you switched to a different mode manually (80x72 was not one of them).
The length restriction was more for printing purposes, so lines where not cut off on the right hand side. Some of us also preferred it for terminal viewing, but that was a secondary reason for the restrictions. Now days I rarely print code, but when I do I usually need to reformat it so that it either does not wrap lines or cuts it off, dependent on the software used to print it.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I agree
Roger Stoltz wrote: nResult = GetResult(
Param1,
Param2
);
is truly
In general I don't think it's possible to get large numbers of developers to agree on one consistent code style. Everyone has their own style but one thing I thnk we can all agree on is that K&R style -
void CFunc(int param, very_long_type_name_for_demo_purposes a){
//..Insert code here
}
Is bad in the way pepperring your C++ with hexidecimal OpCodes and doing all your math in Octal for no reason is bad. Not matching up {} brackets like this just makes code unreadable and yet I still find developers doing it
'It really is OK you know you're not going to run out of lines in the file' is my usual response (polite version).
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
how to create installer file(msi) in mfc? pls help me
|
|
|
|
|
You asked this question previous did you see my answer?
|
|
|
|
|
I must be some kind of melon head. I'm including <fstream> and don't understand why I can construct an fstream like so
fstream FileDataStream;
FileDataStream.open(fileName, ios::out | ios::ate);
and get things to work
but not
fstream FileDataStream;
FileDataStream.open(fileName, ios::out | ios::noreplace);
because it says
error C2039: 'noreplace' : is not a member of 'basic_ios<char,struct std::char_traits<char=""> >'
I've only looked in the help and checked out "fstream", read the notes about its ctor and seen these flags, I could understand if the 1st one didn't work, I would assume I'm doing something ridiculous, but can't work out how it can recognise some of the mode flags, but not another
If any kind soul can just get me going (I know it tends to be David Crow who comes to the rescue!) I would really appreciate it.
I just want to:
- check if a file (specified by a CString object) exists.
- if it does, I want to nip to the end of the file and start appending data rows
- if it doesn't, I just need to create it, bung in a few lines of header and then put the data rows in it.
I'm embarrassed and ashamed that it's taking me so long to get this to work as I'm sure in days gone by I must have done this a hundred times!
aaarrrggghhhhh!
|
|
|
|
|
just so you don't think I am not writing anything, here is what I've got so far, please do not laugh
void CTestFolderBrowseDlg::OnSaveentry()
{
// TODO: Add your control notification handler code here
int sel = m_Table.GetSelectionMark();
if(sel < 0)
return; // ERROR no selection
// Build Target File Name
if(!pathLoaded)
return; // ERROR no path info
CString energyText;
energyText = m_Table.GetItemText(sel, 0);
CString fileName(path);
fileName += '\\';
if(energyText.GetLength()<2) fileName += "0";
energyText += "MeV.dat";
fileName += energyText;
// Check if File Exists
fstream FileDataStream;
FileDataStream.open(fileName, ios::out | ios::ate); // note, the noreplace flag doesnt work
if(FileDataStream.is_open())
{
// file exists (I think without noreplace, it's always going to end up in here)
// Read Data
// Append Data
FileDataStream<
|
|
|
|
|
just curious : why are you creating a fstream if you only need to write to the file ? doesn't a ofstream suffice ?
|
|
|
|
|
ldsdbomber wrote: I've only looked in the help and checked out "fstream"...
But you did not look in ios.h , which is included by fstream.h . With the newer header files, the noreplace and nocreate flags were removed.
ldsdbomber wrote: - check if a file (specified by a CString object) exists.
How about _access(str, 0) ? Or just try to open the file for reading. If that fails, the file likely does not exist.
ldsdbomber wrote: - if it does, I want to nip to the end of the file and start appending data rows
Have you tried ios::app ?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|