|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
There's real code and academic code. If you had all the time in the world then sure, make your code as beautiful as you want, add any amount of abstraction you want etc. In reality, you get to work on some project, most likely you join it in the middle or near the end of development cycle. You have a deadline that doesn't allow you to do much (Unit testing? You're joking, right?). What counts there is that you look at a single piece of code from the framework you haven't seen before and you must know what to do with it. It's all that matters, you don't have 2 days to spare figuring out how the entire framework is built and what's going on under the hood, you must do x in feature y by the end of date z - that's all that concerns you.
In such situations you don't care how badly the code is formatted, if it's commented or not. All you care about is if you see a small piece of code taken from a bigger project and with just this small piece how fast can you either alter it or use it to get specific result in your timeframe.
In the beginning I was a big proponent of all the "clean code", SOLID and all that stuff. Right now I'm in favor of duct tape programming. But I never forget about the past, so if I ever find a badly formatted or badly written code and I have a minute or two to spare I'll make even a small piece of it better. This way, as I work through numerous tasks I'm not only introducing new code that's "good enough" in my eyes, I slowly make improvements to the old code to meet the same standards.
On another note, do you also hate it when you encounter this?
catch (Exception $ex) {
// do nothing
}
|
I feel like people who speak of 'elegant' code and 'beautiful' code have not had to deal with large-scale development on a real production code base ... good code is : efficient, re-usable, maintainable and easy to understand, thats it. No tricks, no cleverness, no abstract concepts that make good code.
|
is there something to be said about completely abstract code
beyond vacuous hogwash and tired truisms?
i think not!
|
I guess it depends on what do you consider an abstract code. If you use a layer of abstraction to make it more readable and easier to use then by all means do so, but if you start introducing multiple layers of abstraction just for the sake of making it abstract you're most likely doing something wrong.
I'm not the most experienced developer around so I might be wrong on this though.
|
On January 09 2015 08:53 darkness wrote:Show nested quote +On January 08 2015 10:12 LaNague wrote:I thinkgood programming is something similar to good painting. You have to have a brain for it and you have to practice technique. No matter how much i practiced for my stupid art aclasses in school, in 12 years i did not produce a single good looking picture. And similar, some people in my university are incapable of producing good code, their brain isnt made for it. But university CS degrees arent about programming, you learn mostly other stuff and have some basic programming classes. Same as an art degree is probably not painting things all week (i think?).
hey what would you recommend to programm a little 3d video game? i heared c++ is the best for this?
what libaries would i need besides opengl? i would need something to load files with sound, images, 3d models etc. Which SDK can offer all that. I am looking for something that makes life easy. But i want to go the professional way
that totally depends. If you just want to get it over with and design your game and dont care that you cant really tune everything, then Unity or a similar engine. It can also be used in C# for example. If you are in it for the experience or need something custom, then you need C++ with either directX or openGL. Also, there are shades between those 2 options, but im not a game programmer so i dont know whats hot right now regarding that. Come on, this is bullshit. You should probably define what you mean by good code, but if you mean readable, then all it takes is to read the book 'Clean Code' by Robert Martin. I don't think one has to have an excellent brain, it is just a discipline.
http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf
here, bullshit right back to you
|
On January 10 2015 11:27 Manit0u wrote:
I guess it depends on what do you consider an abstract code. If you use a layer of abstraction to make it more readable and easier to use then by all means do so, but if you start introducing multiple layers of abstraction just for the sake of making it abstract you're most likely doing something wrong.
I'm not the most experienced developer around so I might be wrong on this though.
literally abstract code.
existing in thought or as an idea but not having a physical or concrete existence.
|
On January 10 2015 05:41 spinesheath wrote:Show nested quote +On January 10 2015 05:25 ComaDose wrote:
but what if you can make it work faster with a more convoluted method? good code is also a function of the requirements and weighted criteria. Then there's a good chance I'll scold you for thinking about optimization before profiling. Also then there likely is a way to make it faster without convoluting the code.
Hmm. No? There are plenty of examples of more complex algorithms (more "convoluted" if you will, and definitely harder to read) that solve the same problem as the clean naive understandable way but with better complexity (so, faster for large enough instances). Going from O(n^3) to O(n^2.81) is sometimes worth the work and the harder readability.
I think ComaDose was right in that what makes the code good largely depends on what it needs to achieve in which circumstances.
|
On January 10 2015 08:59 Manit0u wrote:On another note, do you also hate it when you encounter this?
catch (Exception $ex) {
// do nothing
}
It's not as bad as the same thing without any comment at all. In your case, at least there's hope that someone spent a moment to consider if this piece of code works properly. Still, they likely eat a whole suite of exceptions that they didn't mean to eat.
On January 10 2015 12:10 ZenithM wrote:Show nested quote +On January 10 2015 05:41 spinesheath wrote:On January 10 2015 05:25 ComaDose wrote:
but what if you can make it work faster with a more convoluted method? good code is also a function of the requirements and weighted criteria. Then there's a good chance I'll scold you for thinking about optimization before profiling. Also then there likely is a way to make it faster without convoluting the code. Hmm. No? There are plenty of examples of more complex algorithms (more "convoluted" if you will, and definitely harder to read) that solve the same problem as the clean naive understandable way but with better complexity (so, faster for large enough instances). Going from O(n^3) to O(n^2.81) is sometimes worth the work and the harder readability. I think ComaDose was right in that what makes the code good largely depends on what it needs to achieve in which circumstances.
Again, a performance gain only ever matters if you 1) have a performance problem and 2) profiled the program to find the critical code. If you get a piece of code from O(n^10) to O(log(n)) but that code never was responsible for more than 1% of the runtime, you wasted development time and possibly readability.
Second part of the issue is that only a very small part of your code will ever be performance critical. The vast majority of it has next to no effect on performance. Obviously there may be a case where you have to sacrifice readability for performance, but in the grand scheme of things these parts are drowned by all the code that isn't performance critical. I'm not going to change the my opinion of what good code is just because <1% of a code base has a chance to require special treatment.
|
On January 10 2015 18:40 spinesheath wrote:Show nested quote +On January 10 2015 08:59 Manit0u wrote:On another note, do you also hate it when you encounter this?
catch (Exception $ex) {
// do nothing
}
It's not as bad as the same thing without any comment at all. In your case, at least there's hope that someone spent a moment to consider if this piece of code works properly. Still, they likely eat a whole suite of exceptions that they didn't mean to eat.
The comment was added by me. I see catch (Exception $ex) {} on a daily basis... Annoys the hell out of me.
|
On January 10 2015 18:59 Manit0u wrote:Show nested quote +On January 10 2015 18:40 spinesheath wrote:On January 10 2015 08:59 Manit0u wrote:On another note, do you also hate it when you encounter this?
catch (Exception $ex) {
// do nothing
}
It's not as bad as the same thing without any comment at all. In your case, at least there's hope that someone spent a moment to consider if this piece of code works properly. Still, they likely eat a whole suite of exceptions that they didn't mean to eat. The comment was added by me. I see catch (Exception $ex) {} on a daily basis... Annoys the hell out of me.
Assuming that this isn't an example where one was just too lazy to check the error condition and instead lets it throw an exception...
I've iterated to logging something out in these cases if I'm going to catch instead of the do nothing comment...usually wrapped in a debug enabled statement so it normally doesn't do anything. It's equivalent in cases where the logger is not set to debug, and _way_ better when you know to know why you are getting into that exception block.
On January 10 2015 08:59 Manit0u wrote:
There's real code and academic code. If you had all the time in the world then sure, make your code as beautiful as you want, add any amount of abstraction you want etc. In reality, you get to work on some project, most likely you join it in the middle or near the end of development cycle. You have a deadline that doesn't allow you to do much (Unit testing? You're joking, right?). What counts there is that you look at a single piece of code from the framework you haven't seen before and you must know what to do with it. It's all that matters, you don't have 2 days to spare figuring out how the entire framework is built and what's going on under the hood, you must do x in feature y by the end of date z - that's all that concerns you.
In such situations you don't care how badly the code is formatted, if it's commented or not. All you care about is if you see a small piece of code taken from a bigger project and with just this small piece how fast can you either alter it or use it to get specific result in your timeframe.
In the beginning I was a big proponent of all the "clean code", SOLID and all that stuff. Right now I'm in favor of duct tape programming. But I never forget about the past, so if I ever find a badly formatted or badly written code and I have a minute or two to spare I'll make even a small piece of it better. This way, as I work through numerous tasks I'm not only introducing new code that's "good enough" in my eyes, I slowly make improvements to the old code to meet the same standards.
There is a lot of truth to this... I've seen it practiced and even for myself usually always prefer the duct tape solution even if its not the one chosen.
I've also seen what 15 years of duct tape solutions can do to a code base, especially when developers are coming and going. Some of them were probably good at the boy scout method (leaving it better than you found it ) type of approach that you mention. Others struggle... making changes is extremely difficult because being able to read the code and comprehend the effect of change you are introducing is either extremely time consuming or too difficult without giving up and pitching a rewrite.
After years of "duct taping", I've had the fortune over the past couple years of leading the new projects at our company while being given the time to try to write "clean code" and focusing on automated testing. Between the technical debt, slower velocity due to modifying a 15 yr old code base, and lack of automated regression testing... it's not hard to understand why management sees value in allowing for us to "try to get it right this time".
There is obviously a lot of value in taking the time to structure your code correctly and adding automated testing of some sort. I'm really curious to see whether it ends up being worth it and actually can lead to continued velocity over the years.
|
On January 10 2015 20:24 berated- wrote:Show nested quote +On January 10 2015 18:59 Manit0u wrote:On January 10 2015 18:40 spinesheath wrote:On January 10 2015 08:59 Manit0u wrote:On another note, do you also hate it when you encounter this?
catch (Exception $ex) {
// do nothing
}
It's not as bad as the same thing without any comment at all. In your case, at least there's hope that someone spent a moment to consider if this piece of code works properly. Still, they likely eat a whole suite of exceptions that they didn't mean to eat. The comment was added by me. I see catch (Exception $ex) {} on a daily basis... Annoys the hell out of me. Assuming that this isn't an example where one was just too lazy to check the error condition and instead lets it throw an exception... I've iterated to logging something out in these cases if I'm going to catch instead of the do nothing comment...usually wrapped in a debug enabled statement so it normally doesn't do anything. It's equivalent in cases where the logger is not set to debug, and _way_ better when you know to know why you are getting into that exception block. Show nested quote +On January 10 2015 08:59 Manit0u wrote:
There's real code and academic code. If you had all the time in the world then sure, make your code as beautiful as you want, add any amount of abstraction you want etc. In reality, you get to work on some project, most likely you join it in the middle or near the end of development cycle. You have a deadline that doesn't allow you to do much (Unit testing? You're joking, right?). What counts there is that you look at a single piece of code from the framework you haven't seen before and you must know what to do with it. It's all that matters, you don't have 2 days to spare figuring out how the entire framework is built and what's going on under the hood, you must do x in feature y by the end of date z - that's all that concerns you.
In such situations you don't care how badly the code is formatted, if it's commented or not. All you care about is if you see a small piece of code taken from a bigger project and with just this small piece how fast can you either alter it or use it to get specific result in your timeframe.
In the beginning I was a big proponent of all the "clean code", SOLID and all that stuff. Right now I'm in favor of duct tape programming. But I never forget about the past, so if I ever find a badly formatted or badly written code and I have a minute or two to spare I'll make even a small piece of it better. This way, as I work through numerous tasks I'm not only introducing new code that's "good enough" in my eyes, I slowly make improvements to the old code to meet the same standards.
There is a lot of truth to this... I've seen it practiced and even for myself usually always prefer the duct tape solution even if its not the one chosen. I've also seen what 15 years of duct tape solutions can do to a code base, especially when developers are coming and going. Some of them were probably good at the boy scout method (leaving it better than you found it ) type of approach that you mention. Others struggle... making changes is extremely difficult because being able to read the code and comprehend the effect of change you are introducing is either extremely time consuming or too difficult without giving up and pitching a rewrite. After years of "duct taping", I've had the fortune over the past couple years of leading the new projects at our company while being given the time to try to write "clean code" and focusing on automated testing. Between the technical debt, slower velocity due to modifying a 15 yr old code base, and lack of automated regression testing... it's not hard to understand why management sees value in allowing for us to "try to get it right this time". There is obviously a lot of value in taking the time to structure your code correctly and adding automated testing of some sort. I'm really curious to see whether it ends up being worth it and actually can lead to continued velocity over the years.
they should include writing clean code as a class in schools, reading others code without an explanation is just imposable
|
Is anyone here a game developer? What's the excuse of companies like Blizzard not to utilise 4+ cores CPU?
|
Their engines were written when dual core was new / There's not enough gain to go to 4+ cores?
|
On January 12 2015 01:58 darkness wrote:
Is anyone here a game developer? What's the excuse of companies like Blizzard not to utilise 4+ cores CPU?
It won't increase their sales but increases development costs.
|
Fun thing regarding game development and optimization:
![[image loading]](http://www.dsogaming.com/wp-content/uploads/2013/02/CDPR-The-Witcher-3-best-version.jpg)
![[image loading]](http://static.gamespot.com/uploads/original/1503/15036700/2504458-9979005135-24913.jpg)
|
On January 12 2015 01:58 darkness wrote:
Is anyone here a game developer? What's the excuse of companies like Blizzard not to utilise 4+ cores CPU?
Its difficult to make your game scale with as many cores as are available, really really difficult.
Most devs go with as many fixed cores as they can easily develop for
With fixed cores you can for example make parts of the game run on different cores, like sound, physics, main game.
But for scalable cores you want all parts run on all cores, so first you need to develop your software in a way that parts can be run independandly of other parts in resources and in time.
And then you need to develop a scheduler who assigns independent work to all cores, preferrably guessing which work needs to be done in the future and assign this to idle cores.
This is because when using cores, you have to synchronize them in some way, you cant just run 25% of all work on all 4 cores because in the end programs have a sequence of commands that are run one after the other.
This synchronizing, when done wrong, can either lock things up or make them run very slowly(cores withing on other cores to finish and if sone in a circle everything locks up), or in other cases produce wrong results when 2 cores access to same resource at the same time.
|
On January 12 2015 05:39 LaNague wrote:Show nested quote +On January 12 2015 01:58 darkness wrote:
Is anyone here a game developer? What's the excuse of companies like Blizzard not to utilise 4+ cores CPU? Its difficult to make your game scale with as many cores as are available, really really difficult. Most devs go with as many fixed cores as they can easily develop for
Actually it's pretty easy to scale with a flexible number of cores as long as you do the hard part, which is designing your algorithm in a way that allows the bottleneck to be split up into a large number of independent tasks. Once you have an algorithm of the form
foreach(task in independentTasks) { task.Execute(); }you can pick a multithreading framework of your choice, tell it to execute the loop in parallel, and it will distribute the load dynamically. No need to reinvent anything here.
The hard part is transforming the algorithm at the performance bottleneck. I have no idea what exactly the bottleneck is in Blizzard games, so I can't really tell just how hard it would be.
Usually the transformation comes with some overhead, so you need to run a bunch of performance tests on different numbers of cores and potentially come up with a way to switch to the sequential version of the algorithm in case you don't have enough cores to make the overhead worth it. That part is not very hard, but it's a lot of work.
But in the end it really is just too much work and thus too expensive for very little monetary gain.
|
On January 12 2015 06:37 spinesheath wrote:Show nested quote +On January 12 2015 05:39 LaNague wrote:On January 12 2015 01:58 darkness wrote:
Is anyone here a game developer? What's the excuse of companies like Blizzard not to utilise 4+ cores CPU? Its difficult to make your game scale with as many cores as are available, really really difficult. Most devs go with as many fixed cores as they can easily develop for Actually it's pretty easy to scale with a flexible number of cores as long as you do the hard part, which is designing your algorithm in a way that allows the bottleneck to be split up into a large number of independent tasks. Once you have an algorithm of the form foreach(task in independentTasks) { task.Execute(); }you can pick a multithreading framework of your choice, tell it to execute the loop in parallel, and it will distribute the load dynamically. No need to reinvent anything here. The hard part is transforming the algorithm at the performance bottleneck. I have no idea what exactly the bottleneck is in Blizzard games, so I can't really tell just how hard it would be. Usually the transformation comes with some overhead, so you need to run a bunch of performance tests on different numbers of cores and potentially come up with a way to switch to the sequential version of the algorithm in case you don't have enough cores to make the overhead worth it. That part is not very hard, but it's a lot of work. But in the end it really is just too much work and thus too expensive for very little monetary gain.
Yeah, essentially the game engine itself needs to be built for multi-threading from the ground up with all the associated overhead, which is substantial, figured out ahead of time. There's a reason the ratio of number of game engine developers vs number of game developers is at least 1:1000+; it's not something a kid straight out of college can do, or something you ship off to India and have them figure it out.
Sure, even without the engine fundamentally being multi-threaded you can always multi-thread afterwards, but that leads to exactly where we are now where 1 core does a huge majority of the work and the other cores still do a work but not nearly enough.
Game development is not a glamorous position (in terms of pay) and you need very talented engineers and time to figure out concurrency for something as complicated as a game engine.
|
On January 10 2015 20:32 sabas123 wrote:Show nested quote +On January 10 2015 20:24 berated- wrote:On January 10 2015 18:59 Manit0u wrote:On January 10 2015 18:40 spinesheath wrote:On January 10 2015 08:59 Manit0u wrote:On another note, do you also hate it when you encounter this?
catch (Exception $ex) {
// do nothing
}
It's not as bad as the same thing without any comment at all. In your case, at least there's hope that someone spent a moment to consider if this piece of code works properly. Still, they likely eat a whole suite of exceptions that they didn't mean to eat. The comment was added by me. I see catch (Exception $ex) {} on a daily basis... Annoys the hell out of me. Assuming that this isn't an example where one was just too lazy to check the error condition and instead lets it throw an exception... I've iterated to logging something out in these cases if I'm going to catch instead of the do nothing comment...usually wrapped in a debug enabled statement so it normally doesn't do anything. It's equivalent in cases where the logger is not set to debug, and _way_ better when you know to know why you are getting into that exception block. On January 10 2015 08:59 Manit0u wrote:
There's real code and academic code. If you had all the time in the world then sure, make your code as beautiful as you want, add any amount of abstraction you want etc. In reality, you get to work on some project, most likely you join it in the middle or near the end of development cycle. You have a deadline that doesn't allow you to do much (Unit testing? You're joking, right?). What counts there is that you look at a single piece of code from the framework you haven't seen before and you must know what to do with it. It's all that matters, you don't have 2 days to spare figuring out how the entire framework is built and what's going on under the hood, you must do x in feature y by the end of date z - that's all that concerns you.
In such situations you don't care how badly the code is formatted, if it's commented or not. All you care about is if you see a small piece of code taken from a bigger project and with just this small piece how fast can you either alter it or use it to get specific result in your timeframe.
In the beginning I was a big proponent of all the "clean code", SOLID and all that stuff. Right now I'm in favor of duct tape programming. But I never forget about the past, so if I ever find a badly formatted or badly written code and I have a minute or two to spare I'll make even a small piece of it better. This way, as I work through numerous tasks I'm not only introducing new code that's "good enough" in my eyes, I slowly make improvements to the old code to meet the same standards.
There is a lot of truth to this... I've seen it practiced and even for myself usually always prefer the duct tape solution even if its not the one chosen. I've also seen what 15 years of duct tape solutions can do to a code base, especially when developers are coming and going. Some of them were probably good at the boy scout method (leaving it better than you found it ) type of approach that you mention. Others struggle... making changes is extremely difficult because being able to read the code and comprehend the effect of change you are introducing is either extremely time consuming or too difficult without giving up and pitching a rewrite. After years of "duct taping", I've had the fortune over the past couple years of leading the new projects at our company while being given the time to try to write "clean code" and focusing on automated testing. Between the technical debt, slower velocity due to modifying a 15 yr old code base, and lack of automated regression testing... it's not hard to understand why management sees value in allowing for us to "try to get it right this time". There is obviously a lot of value in taking the time to structure your code correctly and adding automated testing of some sort. I'm really curious to see whether it ends up being worth it and actually can lead to continued velocity over the years. they should include writing clean code as a class in schools, reading others code without an explanation is just imposable
It's not so much one class that teaches it, but enforcement of good code formatting/styling across all classes. Most universities have a "Programming Practices"-type class, but it can only do so much. At mine, that class was in second year and was mandatory, but by third year, most people were back to old habits and submitting mostly uncommented, awfully formatted nightmares outside of cases where it was required by the class (software engineering class, etc). Of the classes I took, most of the upper year classes asked for commented code, but outside of my systems programming class, there seldom were style/formatting guides used or enforced. It basically seems like a case of people not putting any thought into making actual clean, readable code unless there is incentive to do so.
|
|
|
|
|
|
|
|
EPT
