Survey Results

FirstPrevNext

Re: Entropy Rules Chris Maunder31-Jul-02 14:08 Chris Maunder 31-Jul-02 14:08  Reverend Stan wrote: I always end up wondering who the heck wrote that pile of crap while I wasn't looking. You too? Man - whoever it is sure gets around. cheers, Chris Maunder Re: Entropy Rules ColinDavies31-Jul-02 17:35 ColinDavies 31-Jul-02 17:35  Yeah, I feel physically sick when I look at my old code also. Regardz Colin J Davies Sonork ID 100.9197:Colin You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me. Re: Entropy Rules Paul Watson4-Aug-02 1:41 Paul Watson 4-Aug-02 1:41  Reverend Stan wrote: I also make every effort to make my code as neat as possible. But at the end of the development cycle I always end up wondering who the heck wrote that pile of crap while I wasn't looking You should have seen me agonising over every line before I submitted that CP+ thing. While I was writing it I was thinking "this rocks", but once it was ready to be submitted I checked over my code and though "god, they are going to have a good laugh at this." And I kept looking for the Format Code button for C++ in VS.NET. No such luck... lol. regards, Paul Watson Bluegrass Cape Town, South Africa Re: Entropy Rules George4-Aug-02 3:02 George 4-Aug-02 3:02  Paul Watson wrote: And I kept looking for the Format Code button for C++ in VS.NET. No such luck... lol. Are you sure? Boy, they really screwed the IDE then... Formatting is important because.... Roger Allen29-Jul-02 5:30 Roger Allen 29-Jul-02 5:30  I can't see how anybody would go for an option other than this. All code must go through a development/debug/maintenance cycle. So go for anything else would be professional suicide, but thats just my opinion. Sure, depending on peformance you *may* have to compromise*, but with the speed of todays and future computers, this should be less of an issue as time goes by. * I have never yet had to compromise, and I write real time apps for instrument control. Roger Allen Sonork 100.10016 If I had a quote, it would be a very good one. Re: Formatting is important because.... James R. Twine29-Jul-02 7:42 James R. Twine 29-Jul-02 7:42  Roger Allen wrote: Sure, depending on peformance you *may* have to compromise*, but with the speed of todays and future computers, this should be less of an issue as time goes by.    I have never seen a situation that has suffered reduced performance due to formatting concerns.  And, I honestly believe that anyone who greatly reduces the performance of code (note that certain temporaries are usually optimized out) by doing formatting changes likely is someone that is not qualified to make those changes!    Peace! -=- James. "There is nothing worse than being oblivious to the fact that you do not know what you are doing." [Get Check Favorites 1.4 Now!] Re: Formatting is important because.... Armen Hakobyan29-Jul-02 11:31 Armen Hakobyan 29-Jul-02 11:31  If there are different people involved in one project it seems to me that much better to have the code well-formatted and use Hungarian notation than headache translating it to understand, imagine everyone in the street began to drive just the way he likes #define __ARMEN_H__ Re: Formatting is important because.... UltraJoe30-Jul-02 1:49 UltraJoe 30-Jul-02 1:49  I agree with the formatting (but NOT with the Hungarian Notation idea!!! ). However, I've seen this go way over the edge, too, with "style guides" that mandate a particular number of spaces to indent, that all constants (even 0 and 1) must be #define'd (even when 0 and 1 would make more sense), or other things so piddly and against the development environment that it becomes more work to maintain the formatting vs. maintaining the code. (Regarding my anti-Hungarian Notation thing, in my 20+ years of experience, I've rarely needed to know at a particular spot what type a variable is supposed to be, but I've often needed to know what the purpose for a variable is. Sorry, but lpszText doesn't tell me beans. What's the text supposed to contain? Besides, it can be a maintenance nightmare when you discover that you need to change the datatype for whatever reason (e.g., it comes from an external source, and it changes from an int to a float).) Re: Formatting is important because.... Armen Hakobyan30-Jul-02 6:37 Armen Hakobyan 30-Jul-02 6:37  But lpszAppPath tells. #define __ARMEN_H__ Re: Formatting is important because.... UltraJoe30-Jul-02 7:55 UltraJoe 30-Jul-02 7:55  So does appPath, and you don't have to worry about changing it from char* to CString. Re: Formatting is important because.... Armen Hakobyan30-Jul-02 11:53 Armen Hakobyan 30-Jul-02 11:53  The name lpszAppPath makes clear its type and what methods to use without going to its definition. And how often do you change char* to CString ? #define __ARMEN_H__ Re: Formatting is important because.... UltraJoe31-Jul-02 8:04 UltraJoe 31-Jul-02 8:04  Armen Hakobyan wrote: The name lpszAppPath makes clear its type and what methods to use without going to its definition. IMHO, I'd rather go back to the definition (and be sure somebody didn't change the type without changing the name!) than to wade through the garbage just to find the purpose of the identifier. Armen Hakobyan wrote: And how often do you change char* to CString ? During prototyping, more often than one might think. Re: Formatting is important because.... Armen Hakobyan31-Jul-02 11:47 Armen Hakobyan 31-Jul-02 11:47  Ok ok. #define __ARMEN_H__ Re: Formatting is important because.... Philip Patrick31-Jul-02 1:56 Philip Patrick 31-Jul-02 1:56  appPath doesn't say nothing to me except that this is a path and suppose to be some sort of string, thought it doesn't have. We, for example, have paths defined in Database, so the path can be actually a long variable - ID in DB. See? Now I saw appPath and have NO idea what you mean by that, I have to go and search where it was defined, and if you hate HN, you won't use "m_" declaration for class members also, so your variable can be define anywhere. This increases programming time of your product for example. BUT if you had declared your variable lpszAppPath, I can be sure that this is a string (LPCTSTR), or if you declared nAppPath (in our particular case) I know that this is an ID to path in Database. Simple as is Philip Patrick Web-site: www.stpworks.com "Two beer or not two beer?" Shakesbeer Re: Formatting is important because.... UltraJoe31-Jul-02 8:09 UltraJoe 31-Jul-02 8:09  appPath tells me that it's the path to some sort of application; the details would depend on context. However, that gives me significantly more useful information than, say, lpszText, which tells me the datatype, but not how the stupid thing is used. HN requires the developers to keep all occurrences of the identifier consistent with its datatype. I'd much rather go back to its definition, where I can see in detail what the compiler thinks it's supposed to be, than risk making a bad assumption. But we've gone way off topic here. Re: Formatting is important because.... Philip Patrick31-Jul-02 9:36 Philip Patrick 31-Jul-02 9:36  Well, noone talking about lpszText, but about lpszAppPath, which tells you type AND what this variable for. UltraJoe wrote: I'd much rather go back to its definition, I suppose that you mean a small project, maybe 1-2 classes/cpp files in it. But think about something bigger. Example is not very far - in my company, there are like 30 different modules (.dll and .exe) written by different people. And you use someone else's module and you have no idea in it, you just use it. So to know the type you should find where the variable is declared. It can be global, it can be member of class or just local to the function. Using your method, you can't do that without searching for definition, which can take a lot of time, or maybe you should go to that programmer who did the module and ask him? I would fire you for disturbing people by asking such questions lol, or maybe that programmer who has no idea in HN, depends on situation. I tested that on my own skin, we had some people who liked to call their variables like database_connection. Yeah it says what is that, but what type? ADO Connection object? MFC connection? Just a connection string? And is this a pointer? Philip Patrick Web-site: www.stpworks.com "Two beer or not two beer?" Shakesbeer Re: Formatting is important because.... UltraJoe1-Aug-02 10:01 UltraJoe 1-Aug-02 10:01  Philip Patrick wrote: Well, noone talking about lpszText, but about lpszAppPath, which tells you type AND what this variable for. Okay, I'm probably not playing fair by changing examples in mid-stream; I should've used lpszText from the start. Still, I'd much rather search for the definition (more on that in a second) than trip over the semantics of a line of code by trudging through all the Hungarian junque. For me, the understandability of the code decreases exponentially as I see more "lpsz" garbage. Numerous people have noted that searching for a definition can be tedious. I disagree; it won't be tedious IF the project is organized well, not just in terms of classes or a single file, but also in terms of what goes into what files. An undecorated name is either an argument to the current function/method, in the class or a superclass thereof, or a global . (No, I'm not trying to claim that globals are good, nor am I condemning them. Completely different subject.) That makes 3 places to look, and that's it. More often than not, I'll need that file anyhow, for comments relating to the variable (when necessary), or other information that won't come from Hungarian Notation anyhow. Re: Formatting is important because.... KarstenK30-Jul-02 1:10 KarstenK 30-Jul-02 1:10  Totally right, the format enhances transparency. Only well formatted and commentented code enables to work other programmers than the original coder on the source. AND: in well formatted code experienced programmers see the quality or bugs at first side. Re: Formatting is important because.... Marc Clifton31-Jul-02 11:51 Marc Clifton 31-Jul-02 11:51  All code must go through a development/debug/maintenance cycle. Right. In the land of Oz. I've preached that to various companies (like Robot Research, eventually bought by Sensormatic), or like Integration Partners, when I worked for them. Management barely understand why a debug cycle is necessary ("can't you just program it without bugs???") and I've never been able to convince any manager that a product needs to be funded for the maintenance cycle, let alone a phase-out cycle. I'm sick of it all, which is why I'm a consultant now. And I'm sick of it enough that I'm naming the bozo places I used to work for, otherwise, there will never be accountability. As far as style goes, other than getting the naming convention right, it's cheaper to buy a code formatter than to get two people, let alone 10 or 20, to agree on style. Marc If it looks bad, it most likely runs bad as well... George28-Jul-02 21:00 George 28-Jul-02 21:00  Poor programmers usually suck at both code formatting and code performance. If you see a bad looking code you can be sure it will give you a headache. Re: If it looks bad, it most likely runs bad as well... Alexandru Savescu28-Jul-02 23:21 Alexandru Savescu 28-Jul-02 23:21  George wrote: Poor programmers usually suck at both code formatting and code performance. It depends! I like to indent a la MS-stlye, I use a lot of blank lines to separate program functionality etc. I hate Java-formatting style However I have collegues that do not use blank lines, use Java-indentation etc. But, their code is good, just does not look nice to me. Best regards, Alexandru Savescu Re: If it looks bad, it most likely runs bad as well... George29-Jul-02 3:26 George 29-Jul-02 3:26  Alexpro wrote: It depends! Of course! Alexpro wrote: However I have collegues that do not use blank lines, use Java-indentation etc. But, their code is good, just does not look nice to me. Well, I am not talking about Java-style vs MS-Style. I am rather talking about having and not having a style. Some people really can make a code look unreadable, because they don't format it at all. Re: If it looks bad, it most likely runs bad as well... Anonymous29-Jul-02 22:32 Anonymous 29-Jul-02 22:32  bla bla bla whaterver dude bla bla bla Re: If it looks bad, it most likely runs bad as well... Tim Smith31-Jul-02 5:13 Tim Smith 31-Jul-02 5:13  I guess you are a spew coder then? Tim Smith "Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution." Hoare - 1980 ACM Turing Award Lecture Re: If it looks bad, it most likely runs bad as well... Mike Pulice30-Jul-02 12:06 Mike Pulice 30-Jul-02 12:06  I agree with that statement. I think its a matter of pride. I want it to look good and work good. If my seniors and principles look at my code or go through a code review and it looks like garbage and confusing then i did not do my job! My job is to write clear and concise code that works according to spec. mike Mike "Badvox"

Last Visit: 31-Dec-99 18:00     Last Update: 29-Apr-24 4:47 Refresh ᐊ Prev1234 Next ᐅ

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.