|
CodeWraith wrote: Sander Rossel wrote: Also, it's not like the 1000 lines are very memory efficient (or efficient in any other way)! Sure they are, you save a lot of memory by not having to call functions, not having to pass parameters and also quite a bit of space on the stack. On a modern system with plenty of memory that does not help very much and does certainly not justify all the disadvantages, but it does have this one advantage (as long as there is no code redundancy). I was talking about the 1000 lines of code I have to work with
|
|
|
|
|
Some other poor fool wrote it. Since only we two may have good reasons for doing something like this, this of course is an outrage. Have him tarred, feathered, first thrown out of the guild and subsequently out of the town as well.
|
|
|
|
|
CodeWraith wrote: Sure they are, you save a lot of memory by not having to call functions, not having to pass parameters and also quite a bit of space on the stack. That depends... Frequently, 1000 lines of code will contain like or similar code constructs. Factoring such parts out might save significant code space. Also, data values are frequently used only during certain stages. Factoring out these might save data space as weel.
I work for a company that shiftet from an 8-bit processor (8051) to a 16-bit one (ARM) a few years ago. Not until the porting job was done did it become clear how much code really was there just to overcome the 8 bit limitations. Once the 8-bit problems were gone, we could write far more straightforward and simple code (all in plain C). For identical functionality, the 16-bit code was frequently smaller. (Sure, the ARM 'Thumb' instruction subset plays an important part in that.) Data size did grow after porting, but not that much.
We have never looked back. 8-bit processors may be cheap as chips, but extremely costly in code development and maintenance; you spend a large part of your energy on overcoming the limitations of the processor. Migrating to even the smallest ARMs (like the M0) will give you freedom you never felt before . Those tiny ARMs are also quite cheap, so the cost argument in favor of 8-bit CPUs more or less vanish.
Of course: I am talking about systems that can be organized around a general MPU with on-chip peripherals. There may be uses where the major part of the chip area is some very specialized logic design that would cost a fortune to move to another chip. We did move a good deal of additional logic, at a significant cost, but again: That gave us a great opportunity to clean up the logic design. If you cannot possibly do a similar move ... I feel pity for you...
|
|
|
|
|
That's how I read the OP's comment.
|
|
|
|
|
For that reason code reviews are indispensable.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
It's the guy who does the reviews that writes such horrible code...
|
|
|
|
|
When teaching at a tech college I made myself a lot of enemmies among the students (fortunately, they were last year students ) by organizing a large project in four stages. For each stage, each project team would take over the results from another team, done in the preceeding stages.
Even as last year students, they would not at all accept that in half a year, that would be their normal working mode: Taking over the work of other people, leaving their own work for someone else to take further. Throughout 16 years of schooling, they had never before experienced such a thing, and they found it utterly meaningless to be forced to do so in this project.
What they hated the most was not having to clean up the code of others (which all the teams thought themselves perfectly capable of doing), but to give their own work over to classmates, revealing to them all their shortcoming and weaknesses. When I forced them to do that, it was like ordering them to strip naked in front of the class.
I am quite sure that after a year in a programming position, most of them were perfectly comfortable with exchaning code with others. But I was truly shocked seing how intense objections against it they had in their last few months of college course work before becoming IT professionals.
|
|
|
|
|
You deserve a medal!
|
|
|
|
|
Yeah its really depend on that someone. Don't know if it's just me, but I really hate inherit projects developed by "Self-taught" programmers. Nothing seems to flow well and the code are just spaghetti duct-taped it together.
|
|
|
|
|
I AM a self-taught programmer...
Well, I was taught.
By someone who didn't think we needed interfaces because we had base classes, wrote SQL code directly in forms and wrote 100s of lines long functions.
Be glad I taught myself a thing or two
|
|
|
|
|
Oh... That's easy... CTRL+A/Del...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
meets ALL the requirements....? I think requirements will not stop until last user ....DEAD !
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
modified 24-Jul-17 4:41am.
|
|
|
|
|
I wouldn't be surprised if their will has a paragraph of features to add after they die
|
|
|
|
|
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
I completely agree
|
|
|
|
|
And a software application is never finished until the project is retired.
|
|
|
|
|
The survey requires a rating for every item, but I do not have a rating for all of them.
Ratings must be optional.
|
|
|
|