In software development the "me/I/my" code doesn't work well in large development projects or anything close to trying to implement any type software engineering practices.
As I've already said, I'm not interested in working with others. I'm only interested in working alone. If somebody wants to work on (or with) my code they can do so, but on my terms. This has happened several times with my clients, and after the initial steep learning curve they have successfully understood and modified my code. They have even come to appreciate my design and style.
Once you start owning the code in the sense that you don't care who else reads it, the code is already non-useful for future enhancement.
I don't agree. I'm not specifically trying to make the code hard to read or hard to maintain. I'm making it easy for me to read and easy for me to maintain. There are others like me, and people who aren't can learn to deal with my style if they must work with my code.
On the flipside, it drives me nuts to look at code that is sparse. Code that has blank lines and/or only one trivial statement per line annoys me. Even worse is when every line has a comment (on a separate line, of course) that says something like, "Now we increment the pointer." As if I couldn't figure that out from "p++;"!
While this annoys me, I don't tell those people that they should code like me. I simply don't look at and/or use their code unless I really have to. Fortunately for me, I almost never have to.
Also, there are different reason one develops programs.
That's a good point. At this point in my career, I only do things because I think they are fun. People who hire me understand that I'm not really a typical programmer.
Again, since you put your code for thousands of reviewers, don't take anything said here too harshly. I'm sure we are only trying to help for you to become a better developer and more profitable.
I do appreciate all of the comments and I'm not offended by any of them. I enjoy the debate. I am always trying to be a better developer, believe it or not.:)
In that note, buy any type of University level Software Engineering book and read (thoroughly) the OO design chapter - Software methodologies haven't changed much since '93, however, in 11 years there are many writers and developers who have written good books on our chosen trade
I did learn OO design in college. I feel that I understand the fundamentals pretty well. I'm not that into reading books that try to tell me how to do things. I find that it prejudices me towards a particular solution. I get pleasure from doing things "from scratch."
I don't like this. I know that everybody has their own style but I work in a commercial organization that writes Enterprise software and I can tell you that this would not have passed our code reviews.
I have already stated that this style probably isn't right for most people. It works well for me and since I work alone nobody else has to see it.
1- The formatting is too tight. Not enough white space.
I like it precisely because it is tight.
2- Complete absence of comments (big boo boo)
Comments often times only get in the way of understanding the code, especially when a function is fairly small and has an easily understood purpose.
3- Poor indenting (affects readability)
The indenting is what I like. (Note that I left justified all lines to fit better on the/. screen.)
4- Multiple statements on one line (usually a bad idea)
I specifically like to put multiple related statements on one line as long as they fit within 80 columns. If you are expressing one larger idea why not put it all on one line?
Firstly, you may want to read Dijkstra's "Go To Considered Harmful".
I am aware of the arguments against goto. I could have easily wrapped the main portion of the code in a loop and then used break and continue when needed. In fact, that's what I did at first. I then decided that I liked the goto implementation more.
Secondly, your code is full of redundancies. What you are doing can be captured much more clearly by a finite state automaton with an alphabet and transition table.
Can you give a quick example of what you mean?
Finally, because of how this is written, it is completely unconvincing that it is bug-free, even if every line was commented.
Fortunately, the only person I need to convince is me!:)
First, I'd like to thank you for such a thoughtful reply.
It is just harder code to read than what most programmers are used to. The main problem is that there are some changes that are not apparent if you were to skim the method. For example: readMode = cModeTextAuto | fModeTwo | fModeLF; c = LF;
These are good points. I am used to my style, so when I go back and read my own code I pay attention to the entire line. I readily admit that this style isn't necessarily good for situations where others will regularly look at your code.
Having extra line breaks to facilitate reading is a good thing.
Your point is valid and applies to many (maybe most) programmers. For me, however, having extra line breaks makes it harder for me to see the bigger picture and understand more of my code at once.
Just remember that it might not fly so well when working with a team of other programmers.
I don't like to work on projects that involve other programmers. Since graduating from college (in 1993) I have never worked on such a project.
What sort of math are CS majors expected to take? Why are these classes useful? Does programming really have that much to do with math?
The fact that the second and third questions are even asked in a serious (or semi-serious) way reflects a sad state. How can you do any "real" programming without knowing Boolean algebra, theory of computation, integer math, algorithms, etc.
Without knowing the underlying math, how can you understand the logical and arithmetic operations that your CPU can perform? How can you understand whether a given task is solvable? How can you understand how much time a solution should take so that you can compare it to how long it is actually taking?
Please explain. You don't like the way I code? It has served me very well for many years.
You may complain about the absence of comments, but the code I posted was almost the entire function. The purpose of the code is very clear from the function title. Besides, comments just lower the code density and prevent me from seeing as much code per screen.
I realize that my style isn't necessarily good for programmers working as part of a team. I am always the sole programmer on projects I work on.
I have never used code folding. What I do is (of course) try to keep basic blocks short and focused. In addition, I make my code dense by putting multiple short statements on one line if they are related. (Statements that appear near each other are usually related.) I also place a group of several short statments that are the target of an if/while/etc on the same line as the if/while/etc.
What this does is fit a lot more code in the same number of lines (not recommended for LOC whores), meaning you see a lot more code on screen at once.
Here is an example of code I wrote yesterday:
KError error; ichar c; Loop: if (error = Read(&c)) return error; if (KIsFlagSet(readMode,fModeAuto)) {
if (KIsFlagSet(readMode,fModeTwo)) {
if (KIsFlagSet(readMode,fModeCR)) {
if (c == CR) { readMode = cModeTextLFCR; goto Loop; }
else readMode = cModeTextLF;
} else {
if (c == LF) { readMode = cModeTextCRLF; goto Loop; }
else readMode = cModeTextCR;
}
} else if (c == CR) {
readMode = cModeTextAuto | fModeTwo | fModeLF; c = LF;
} else if (c == LF) {
readMode = cModeTextAuto | fModeTwo | fModeCR;
} } else if (c == CR) {
if (KIsFlagSet(readMode,fModeCR)) c = LF;
else if (KIsFlagSet(readMode,fModeToss)) goto Loop; } else if (c == LF) {
if (KIsFlagClear(readMode,fModeCR));
else if (KIsFlagSet(readMode,fModeToss)) goto Loop; }
I was an MIT CS student from 1988-1993 (BS and MS). Part of what made MIT great was that Microsoft's crap wasn't used. MIT has always had a strong "home grown" culture. The software we used was largely developed at MIT, much of it written (at least partly) by other students. You saw, by example, that you could create the tools you need and you don't need to rely on some company's bug filled code to get the job done.
It is sad to think that MIT CS has become (or could become) a showcase for Microsoft tools.
I tried to apply the patch but was unable to. I run NT 4 on my notebook. When I run the patch it says I need to install the latest service pack. When I try to do that it says that if I install the service pack my PCMCIA cards and touchpad will stop working. Nice.
I disabled DCOM using dcomcnfg.exe. I hope that protects me.
Slashdot Mirror
In software development the "me/I/my" code doesn't work well in large development projects or anything close to trying to implement any type software engineering practices.
:)
As I've already said, I'm not interested in working with others. I'm only interested in working alone. If somebody wants to work on (or with) my code they can do so, but on my terms. This has happened several times with my clients, and after the initial steep learning curve they have successfully understood and modified my code. They have even come to appreciate my design and style.
Once you start owning the code in the sense that you don't care who else reads it, the code is already non-useful for future enhancement.
I don't agree. I'm not specifically trying to make the code hard to read or hard to maintain. I'm making it easy for me to read and easy for me to maintain. There are others like me, and people who aren't can learn to deal with my style if they must work with my code.
On the flipside, it drives me nuts to look at code that is sparse. Code that has blank lines and/or only one trivial statement per line annoys me. Even worse is when every line has a comment (on a separate line, of course) that says something like, "Now we increment the pointer." As if I couldn't figure that out from "p++;"!
While this annoys me, I don't tell those people that they should code like me. I simply don't look at and/or use their code unless I really have to. Fortunately for me, I almost never have to.
Also, there are different reason one develops programs.
That's a good point. At this point in my career, I only do things because I think they are fun. People who hire me understand that I'm not really a typical programmer.
Again, since you put your code for thousands of reviewers, don't take anything said here too harshly. I'm sure we are only trying to help for you to become a better developer and more profitable.
I do appreciate all of the comments and I'm not offended by any of them. I enjoy the debate. I am always trying to be a better developer, believe it or not.
In that note, buy any type of University level Software Engineering book and read (thoroughly) the OO design chapter - Software methodologies haven't changed much since '93, however, in 11 years there are many writers and developers who have written good books on our chosen trade
I did learn OO design in college. I feel that I understand the fundamentals pretty well. I'm not that into reading books that try to tell me how to do things. I find that it prejudices me towards a particular solution. I get pleasure from doing things "from scratch."
Thanks for the comments!
I don't like this.
/. screen.)
I know that everybody has their own style but I work in a commercial organization that writes Enterprise software and I can tell you that this would not have passed our code reviews.
I have already stated that this style probably isn't right for most people. It works well for me and since I work alone nobody else has to see it.
1- The formatting is too tight. Not enough white space.
I like it precisely because it is tight.
2- Complete absence of comments (big boo boo)
Comments often times only get in the way of understanding the code, especially when a function is fairly small and has an easily understood purpose.
3- Poor indenting (affects readability)
The indenting is what I like. (Note that I left justified all lines to fit better on the
4- Multiple statements on one line (usually a bad idea)
I specifically like to put multiple related statements on one line as long as they fit within 80 columns. If you are expressing one larger idea why not put it all on one line?
Thanks for the comments.
Firstly, you may want to read Dijkstra's "Go To Considered Harmful".
:)
I am aware of the arguments against goto. I could have easily wrapped the main portion of the code in a loop and then used break and continue when needed. In fact, that's what I did at first. I then decided that I liked the goto implementation more.
Secondly, your code is full of redundancies. What you are doing can be captured much more clearly by a finite state automaton with an alphabet and transition table.
Can you give a quick example of what you mean?
Finally, because of how this is written, it is completely unconvincing that it is bug-free, even if every line was commented.
Fortunately, the only person I need to convince is me!
First, I'd like to thank you for such a thoughtful reply.
It is just harder code to read than what most programmers are used to.
The main problem is that there are some changes that are not apparent if you were to skim the method. For example:
readMode = cModeTextAuto | fModeTwo | fModeLF; c = LF;
These are good points. I am used to my style, so when I go back and read my own code I pay attention to the entire line. I readily admit that this style isn't necessarily good for situations where others will regularly look at your code.
Having extra line breaks to facilitate reading is a good thing.
Your point is valid and applies to many (maybe most) programmers. For me, however, having extra line breaks makes it harder for me to see the bigger picture and understand more of my code at once.
Just remember that it might not fly so well when working with a team of other programmers.
I don't like to work on projects that involve other programmers. Since graduating from college (in 1993) I have never worked on such a project.
What sort of math are CS majors expected to take? Why are these classes useful? Does programming really have that much to do with math?
The fact that the second and third questions are even asked in a serious (or semi-serious) way reflects a sad state. How can you do any "real" programming without knowing Boolean algebra, theory of computation, integer math, algorithms, etc.
Without knowing the underlying math, how can you understand the logical and arithmetic operations that your CPU can perform? How can you understand whether a given task is solvable? How can you understand how much time a solution should take so that you can compare it to how long it is actually taking?
Ok, rant over.
+1 funny, +1 sad
Please explain. You don't like the way I code? It has served me very well for many years.
You may complain about the absence of comments, but the code I posted was almost the entire function. The purpose of the code is very clear from the function title. Besides, comments just lower the code density and prevent me from seeing as much code per screen.
I realize that my style isn't necessarily good for programmers working as part of a team. I am always the sole programmer on projects I work on.
I have never used code folding. What I do is (of course) try to keep basic blocks short and focused. In addition, I make my code dense by putting multiple short statements on one line if they are related. (Statements that appear near each other are usually related.) I also place a group of several short statments that are the target of an if/while/etc on the same line as the if/while/etc.
;
What this does is fit a lot more code in the same number of lines (not recommended for LOC whores), meaning you see a lot more code on screen at once.
Here is an example of code I wrote yesterday:
KError error; ichar c;
Loop: if (error = Read(&c)) return error;
if (KIsFlagSet(readMode,fModeAuto)) {
if (KIsFlagSet(readMode,fModeTwo)) {
if (KIsFlagSet(readMode,fModeCR)) {
if (c == CR) { readMode = cModeTextLFCR; goto Loop; }
else readMode = cModeTextLF;
} else {
if (c == LF) { readMode = cModeTextCRLF; goto Loop; }
else readMode = cModeTextCR;
}
} else if (c == CR) {
readMode = cModeTextAuto | fModeTwo | fModeLF; c = LF;
} else if (c == LF) {
readMode = cModeTextAuto | fModeTwo | fModeCR;
}
} else if (c == CR) {
if (KIsFlagSet(readMode,fModeCR)) c = LF;
else if (KIsFlagSet(readMode,fModeToss)) goto Loop;
} else if (c == LF) {
if (KIsFlagClear(readMode,fModeCR))
else if (KIsFlagSet(readMode,fModeToss)) goto Loop;
}
The median is 5 in your example.
Have you ever seen a light switch on a wall that went left-right and not up-down?
Yes, it's not uncommon. (At least in the U.S.)
I was an MIT CS student from 1988-1993 (BS and MS). Part of what made MIT great was that Microsoft's crap wasn't used. MIT has always had a strong "home grown" culture. The software we used was largely developed at MIT, much of it written (at least partly) by other students. You saw, by example, that you could create the tools you need and you don't need to rely on some company's bug filled code to get the job done.
It is sad to think that MIT CS has become (or could become) a showcase for Microsoft tools.
I tried to apply the patch but was unable to. I run NT 4 on my notebook. When I run the patch it says I need to install the latest service pack. When I try to do that it says that if I install the service pack my PCMCIA cards and touchpad will stop working. Nice.
I disabled DCOM using dcomcnfg.exe. I hope that protects me.