Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualKhatharr

Posted 10 November 2012 - 02:46 PM

These are some things that I've been mulling over myself as I learn more and more about 'proper' coding. I can definitely see the benefits of all the rules and customs developed over the years, but it also strikes me that these things should be measured carefully. If I'm going to write something that needs to last for years to come then I had darn well better "do it right" because in the long run the amount of time saved will be enormous, but on the other hand I see things like "don't use C style things in C++" and in many cases I find myself asking "why the hell not?". It strikes me that rules or customs should be measured based on their effectiveness for the task at hand. In many (even most) cases there's good reasons, but sometimes an array is just a gorram array and using a vector is a waste of time both for the developer and for the CPU at runtime. If I need STL container functionality later it's not difficult to add.

A somewhat related issue, since you mentioned cowboy'ing, if I'm going to write something complex I'll usually sit down and bash it out as quickly as possible and then once its in place I can spot all the structural problems and go back over it (immediately) and write a stable system with all the bells and whistles. I don't want to get stuck spending extra hours writing something that's going to get scrapped or re-written anyway because a better design idea occurred or a structural problem emerged while the code was being written.

I guess what I mean is that I support the K.I.S.S. rule above all others. If something looks and feels complicated then I can't shake the feeling that I'm doing it wrong. I don't understand making something more complex than it needs to be, especially since it seems like complexity is easy to add and hard to remove. Sometimes I feel like the rules and culture are almost a language in and of themselves. It's like C extends to C++ and then C++ extends to 'proper' C++. I've seen criticism about using C++ as if it were C, but the fact is that vanilla C is an effective language as well. In terms of readability C-style is great, but I also find that it seems like the program likes it as well, if that makes any sense. Simple code just usually seems to run better. Algorithms, for instance. I ws looking into algorithms while familiarizing myself with the musty corners of STL and I saw that I could have used an algorithm in place of a loop for iterating through the values in a container and modifying them. Then, by chance, I looked at the code of the appropriate algorithm and saw that it was more or less exactly what I had already written. So all I would gain by implementing the loop with the algorithm is some excess stack framing. On the other hand, there are some situations where algorithms are more or less '****ing rad', to use the technical term, and in those places I gladly use them.

I don't really know where I'm going with this rambling. Like I said, it's just something that's been on my mind. Glad to see other people thinking about it as well.

#5Khatharr

Posted 10 November 2012 - 02:46 PM

These are some things that I've been mulling over myself as I learn more and more about 'proper' coding. I can definitely see the benefits of all the rules and customs developed over the years, but it also strikes me that these things should be measured carefully. If I'm going to write something that needs to last for years to come then I had darn well better "do it right" because in the long run the amount of time saved will be enormous, but on the other hand I see things like "don't use C style things in C++" and in many cases I find myself asking "why the hell not?". It strikes me that rules or customs should be measured based on their effectiveness for the task at hand. In many (even most) cases there's good reasons, but sometimes an array is just a gorram array and using a vector is a waste of time both for the developer and for the CPU at runtime. If I need STL container functionality later it's not difficult to add.

A somewhat related issue, since you mentioned cowboy'ing, if I'm going to write something complex I'll usually sit down and bash it out as quickly as possible and then once its in place I can spot all the structural problems and go back over it (immediately) and write a stable system with all the bells and whistles. I don't want to get stuck spending extra hours writing something that's going to get scrapped or re-written anyway because a better design idea occurred or a structural problem emerged while the code was being written.

I guess what I mean is that I support the K.I.S.S. rule above all others. If something looks and feels complicated then I can't shake the feeling that I'm doing it wrong. I don't understand making something more complex than it needs to be, especially since it seems like complexity is easy to add and hard to remove. Sometimes I feel like the rules and culture are almost a language in and of themselves. It's like C extends to C++ and then C++ extends to 'proper' C++. I've seen criticism about using C++ as if it were C, but the fact is that vanilla C is an effective language as well. In terms of readability C-style is great, but I also find that it seems like the program likes it as well, if that makes any sense. Simple code just usually seems to run better. Algorithms, for instance. I ws looking into algorithms while familiarizing myself with the musty corners of STL and I saw that I could have used an algorithm in place of a loop for iterating through the values in a container and modifying them. Then, by chance, I looked at the code of the appropriate algorithm and saw that it was more or less exactly what I had already written. So all I would gain by implementing the loop with the algorithm is some excess stack framing. On the other hand, there are some situations where algorithms are more or less '****ing rad', to use the technical term.

I don't really know where I'm going with this rambling. Like I said, it's just something that's been on my mind. Glad to see other people thinking about it as well.

#4Khatharr

Posted 10 November 2012 - 02:45 PM

These are some things that I've been mulling over myself as I learn more and more about 'proper' coding. I can definitely see the benefits of all the rules and customs developed over the years, but it also strikes me that these things should be measured carefully. If I'm going to write something that needs to last for years to come then I had darn well better "do it right" because in the long run the amount of time saved will be enormous, but on the other hand I see things like "don't use C style things in C++" and in many cases I find myself asking "why the hell not?". It strikes me that rules or customs should be measured based on their effectiveness for the task at hand. In many (even most) cases there's good reasons, but sometimes an array is just a gorram array and using a vector is a waste of time both for the developer and for the CPU at runtime. If I need STL container functionality later it's not difficult to add.

A somewhat related issue, since you mentioned cowboy'ing, if I'm going to write something complex I'll usually sit down and bash it out as quickly as possible and then once its in place I can spot all the structural problems and go back over it (immediately) and write a stable system with all the bells and whistles. I don't want to get stuck spending extra hours writing something that's going to get scrapped or re-written anyway because a better design idea occurred or a structural problem emerged while the code was being written.

I guess what I mean is that I support the K.I.S.S. rule above all others. If something looks and feels complicated then I can't shake the feeling that I'm doing it wrong. I don't understand making something more complex than it needs to be, especially since it seems like complexity is easy to add and hard to remove. Sometimes I feel like the rules and culture are almost a language in and of themselves. It's like C extends to C++ and then C++ extends to 'proper' C++. I've seen criticism about using C++ as if it were C, but the fact is that vanilla C is an effective language as well. In terms of readability C-style is great, but I also find that it seems like the program likes it as well, if that makes any sense. Simple code just usually seems to run better. Algorithms, for instance. I ws looking into algorithms while familiarizing myself with the musty corners of STL and I saw that I could have used an algorithm in place of a loop for iterating through the values in a container and modifying them. Then, by chance, I looked at the code of the appropriate algorithm and saw that it was more or less exactly what I had already written. So all I would gain by implementing the loop with the algorithm is some excess stack framing.

I don't really know where I'm going with this rambling. Like I said, it's just something that's been on my mind. Glad to see other people thinking about it as well.

#3Khatharr

Posted 10 November 2012 - 02:42 PM

These are some things that I've been mulling over myself as I learn more and more about 'proper' coding. I can definitely see the benefits of all the rules and customs developed over the years, but it also strikes me that these things should be measured carefully. If I'm going to write something that needs to last for years to come then I had darn well better "do it right" because in the long run the amount of time saved will be enormous, but on the other hand I see things like "don't use C style things in C++" and in many cases I find myself asking "why the hell not?". It strikes me that rules or customs should be measured based on their effectiveness for the task at hand. In many (even most) cases there's good reasons, but sometimes an array is just a gorram array and using a vector is a waste of time both for the developer and for the CPU at runtime. If I need STL container functionality later it's not difficult to add.

A somewhat related issue, since you mentioned cowboy'ing, if I'm going to write something complex I'll usually sit down and bash it out as quickly as possible and then once its in place I can spot all the structural problems and go back over it (immediately) and write a stable system with all the bells and whistles. I don't want to get stuck spending extra hours writing something that's going to get scrapped or re-written anyway because a better design idea occurred or a structural problem emerged while the code was being written.

I guess what I mean is that I support the K.I.S.S. rule above all others. If something looks and feels complicated then I can't shake the feeling that I'm doing it wrong. I don't understand making something more complex than it needs to be, especially since it seems like complexity is easy to add and hard to remove. Sometimes I feel like the rules and culture are almost a language in and of themselves. It's like C extends to C++ and then C++ extends to 'proper' C++. I've seen criticism about using C++ as if it were C, but the fact is that vanilla C is an effective language as well. In terms of readability C-style is great, but I also find that it seems like the program likes it as well, if that makes any sense. Simple code just usually seems to run better.

I don't really know where I'm going with this rambling. Like I said, it's just something that's been on my mind. Glad to see other people thinking about it as well.

#2Khatharr

Posted 10 November 2012 - 02:32 PM

These are some things that I've been mulling over myself as I learn more and more about 'proper' coding. I can definitely see the benefits of all the rules and customs developed over the years, but it also strikes me that these things should be measured carefully. If I'm going to write something that needs to last for years to come then I had darn well better "do it right" because in the long run the amount of time saved will be enormous, but on the other hand I see things like "don't use C style things in C++" and in many cases I find myself asking "why the hell not?". It strikes me that rules or customs should be measured based on their effectiveness for the task at hand. In many (even most) cases there's good reasons, but sometimes an array is just a gorram array and using a vector is a waste of time both for the developer and for the CPU at runtime. If I need STL container functionality later it's not difficult to add.

A somewhat related issue, since you mentioned cowboy'ing, if I'm going to write something complex I'll usually sit down and bash it out as quickly as possible and then once its in place I can spot all the structural problems and go back over it and write a stable system with all the bells and whistles. I don't want to get stuck spending extra hours writing something that's going to get scrapped or re-written anyway because a better design idea occurred or a structural problem emerged while the code was being written.

I guess what I mean is that I support the K.I.S.S. rule above all others. If something looks and feels complicated then I can't shake the feeling that I'm doing it wrong. I don't understand making something more complex than it needs to be, especially since it seems like complexity is easy to add and hard to remove. Sometimes I feel like the rules and culture are almost a language in and of themselves. It's like C extends to C++ and then C++ extends to 'proper' C++. I've seen criticism about using C++ as if it were C, but the fact is that vanilla C is an effective language as well. In terms of readability C-style is great, but I also find that it seems like the program likes it as well, if that makes any sense. Simple code just usually seems to run better.

I don't really know where I'm going with this rambling. Like I said, it's just something that's been on my mind. Glad to see other people thinking about it as well.

#1Khatharr

Posted 10 November 2012 - 02:27 PM

These are some things that I've been mulling over myself as I learn more and more about 'proper' coding. I can definitely see the benefits of all the rules and customs developed over the years, but it also strikes me that these things should be measured carefully. If I'm going to write something that needs to last for years to come then I had darn well better "do it right" because in the long run the amount of time saved will be enormous, but on the other hand I see things like "don't use C style things in C++" and in many cases I find myself asking "why the hell not?". It strikes me that someone heard a rule or custom and just repeats it unquestioningly instead of measuring its effectiveness for the task at hand. In many cases there's good reasons, but sometimes an array is just a gorram array and using a vector is a waste of time both for the developer and for the CPU at runtime. If I need STL container functionality later it's not difficult to add.

A somewhat related issue, since you mentioned cowboy'ing. If I'm going to write something complex I'll usually sit down and bash it out as quickly as possible and then once its in place I can spot all the structural problems and go back over it and write a stable system with all the bells and whistles. I don't want to get stuck spending extra hours writing something that's going to get scrapped or re-written anyway because a better design idea occurred or a structural problem emerged while the code was being written.

I guess what I mean is that I support the K.I.S.S. rule above all others. If something looks and feels complicated then I can't shake the feeling that I'm doing it wrong. I don't understand making something more complex than it needs to be. Sometimes I feel like the rules and culture are almost a language in and of themselves. It's like C extends to C++ and then C++ extends to 'proper' C++. There's a lot of criticism about using C++ as if it were C, but the fact is that C is an effective language as well.

I don't really know where I'm going with this rambling. Like I said, it's just something that's been on my mind. Glad to see other people thinking about it as well.

PARTNERS