One of my weaknesses as a semi-pro programmer has always been that I found other people's code very hard to follow. Even my own code a year later was a chore, so I comment the heck out of everything.
My time on this board has brought an unexpected benfit... It's helping me overcome that problem. I find myself actually being able to follow code that's very different than anything I would write.
Didn't expect that.
I wish I were confident enough to say the same. Occasionally, Elysia will post some template code that just boggles my mind, and I don't know why people would want to do that to themselves. I'm sure it makes complete sense, but I look... and just get drowsy... *yaaaawwwn*
Yeah, I still get that wide eyed "What the...." thing going on once in a while. But it is getting easier with time. It will be interesting to see how this affects my own code...
I'm that way, also. Function pointers? Never use 'em - don't always recognize them in other's code, right away.
The comma operator? barely use it.
Triple *** pointers or more? egawd!
Bit fiddling is fast, but unless it's a really natural solution, I avoid them.
The biggest help for my programming, has been through emphasizing clarity and simplicity: better variable naming, and using algorithms that more intuitively match my thinking on solving the problem at hand. If the code I'm writing isn't clear, then I need to re-think the problem, because I don't understand it as well as I should.
Some programs are all about speed, and that's fine. That's going to bring a real constraint on clarity and simplicity (although simple can be pretty quick, too), but I try harder to keep those principles in mind, more than I did previously.
I use function pointers when I don't have any other choice to get the job done. That amounts to twice so far. (Although I do use Windows callbacks fairly often)Originally Posted by Adak
Didn't even know about that one till I saw it here.The comma operator? barely use it.
Exactly... One of the first hints that I don't understand something is that I have trouble coding a solution. I probably spend more time thinking about coding than I actually do coding (much to the dismay of a couple of past employers who were firmly convinced that unless both hands where filled with tools or pounding a keyboard, I was slacking off).The biggest help for my programming, has been through emphasizing clarity and simplicity: better variable naming, and using algorithms that more intuitively match my thinking on solving the problem at hand. If the code I'm writing isn't clear, then I need to re-think the problem, because I don't understand it as well as I should.
I'm very lucky that now I'm retired... no more deadlines! YAY! But yes, I still set goals for myself and try to keep them.Some programs are all about speed, and that's fine. That's going to bring a real constraint on clarity and simplicity (although simple can be pretty quick, too), but I try harder to keep those principles in mind, more than I did previously.
Very interesting stuff... good to know I have some in common with the others here...
Good to hear it's helping you in some way to read our incoherent ramblings around here.
But keep in mind that a lot of code exists that's not really good code. Even in widely used applications. So if you're the sort of person who gets depressed when you don't understand something, remember that it might be the code that's stupid, not yourself.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Yeah but... what if I wrote it?So if you're the sort of person who gets depressed when you don't understand something, remember that it might be the code that's stupid, not yourself.
Seriously though I'm finding that I have one of those "What was he thinking?" reactions when looking at really bad code.
Perhaps I'm a little odd but I don't get depressed when I don't understand something... I tend to get (first) determined and (second) curious... I know, "... killed the cat"... but it's both my curse and my strength.
FWIW... I haven't seen much incoherency around here... some egos to be sure but for the most part I'm enjoying myself.
Microsoft is full of meanies who tried to kill OpenGL, so now we have to use function pointers for any OpenGL past the stone age.
It's always harder to read the code then to write it, and I see it as a very important skill to have.I don't claim to be any good at it, but there are several things I do when I'm reading the code of others: (1) run it through a code formatter, (2) delete all the comments and (3) add my own comments as I read the code and try to make sense of it.
(1) is optional, and I only do it if the code is poorly formatted or the style is too far different from my own. Reason for (2) is that people like to comment what the code does, not what the intent is. Comments like that are only useful for a particularly involved code. Otherwise I prefer that people document their intent. This might be a personal quirk.
Curiosity got framed, IMO. Ignorance killed the cat!
Well, I'm not a scribbler... but I do agree that people should comment on what their code is trying to accomplish not what the C function does... "//open dorsal airlock" tells me a lot more than "//set bit 7" which should be obvious from the code itself.It's always harder to read the code then to write it, and I see it as a very important skill to have.
(1) is optional, and I only do it if the code is poorly formatted or the style is too far different from my own. Reason for (2) is that people like to comment what the code does, not what the intent is. Comments like that are only useful for a particularly involved code. Otherwise I prefer that people document their intent. This might be a personal quirk.
Coming from a Pascal background I never really got into the K&R way of formatting code. My C code looks like Pascal source and I've been chastized about it a couple of times. The problem is that I'm so used to seeing code a certain way, I find the K&R style very hard to read.
Here's a windows code example from a project I'm working on...
Apparently this drives some C programmers to distraction. But I find it to be very compact and easily followed, especially with syntax color highlighting turned on. I also realize this is part of why I find other people's code so hard to follow... it doesn't look right to me.Code:// types list initializer VOID InitTypesList(HWND Dlg) { TVINSERTSTRUCT tvi = {0}; // tree view item struct TCHAR tvt[MAX_TYPENAME] = {0}; // item name DWORD idx = 0; // enum index HTREEITEM tvh; // current item HKEY reg; // association registry key // get treeview handle hTree = GetDlgItem(Dlg,4001); // make sure it's empty TreeView_DeleteAllItems(hTree); // precondition struct tvi.hInsertAfter = TVI_SORT; tvi.item.mask = TVIF_TEXT; tvi.item.cchTextMax = MAX_TYPENAME; tvi.item.pszText = tvt; // enumerate type keys while ( RegEnumKey(REG_RHIVE,idx,tvt,MAX_TYPENAME) != ERROR_NO_MORE_ITEMS) { if (tvt[0] == L'.') { tvh = TreeView_InsertItem(hTree,&tvi); // check file association if (!AssocQueryKey(ASSOCF_NOFIXUPS | ASSOCF_INIT_IGNOREUNKNOWN, ASSOCKEY_CLASS,tvt,NULL,®)) { if (!SHGetValue(reg,REG_RMDATA,NULL,NULL,NULL,NULL)) TreeView_SetCheckState(hTree,tvh,TRUE); RegCloseKey(reg); } } ++ idx; } // set initial item TreeView_SelectItem(hTree,TreeView_GetRoot(hTree)); SetFocus(hTree); }
LOL... cats have no plan.Curiosity got framed, IMO. Ignorance killed the cat!
Curiosity is the most essential thing for gaining knowledge, isn't it?
Several scientists (like Marie Curie and Charles (of "Charles' Law" fame)) have been killed by their work, it's true. Still, some made tremendous advances in science, and could have died on the same day from any number of causes.
I *hate* that style of indentation. Three or four spaces for the opening brace, and some, but not all, closing braces clumped together off to the far right at the end of the line??
What's wrong with having the closing brace lined up right beneath either the first letter of the line of code that originated that block (K&R style), or "textbook" style:
As for comments, I like something above the function briefly describing the functions purpose, and just a few comments as to the particulars (especially for odd code syntax or unusual or complex logic), in the code lines, themselves.Code:for(i=0;i<SIZE;i++) { printf("\n I like the K&R style"); } for(i=0;i<SIZE;i++) { printf("\n I prefer the textbook style"); }
Last edited by Adak; 10-27-2010 at 03:06 AM.
I don't recall the source but: "Curiosity fuels the fires of enlightenment".
It's what makes us want to learn, that's for sure.
Besides, I'd rather be curious than depressed 99 out of 100 times.
