tag:blogger.com,1999:blog-3064325214589649535.post4713226438369646197..comments2024-03-28T06:52:15.545+01:00Comments on Joost's Dev Blog: What most young programmers need to learnJoost van Dongenhttp://www.blogger.com/profile/00569566310604620045noreply@blogger.comBlogger80125tag:blogger.com,1999:blog-3064325214589649535.post-16123974731175174612015-09-09T17:50:53.526+02:002015-09-09T17:50:53.526+02:00Most of the juniors I met doesn't know about O...Most of the juniors I met doesn't know about OOP apart from definition of class, object, abstraction ... even though they know definition they don't understand it, forget about using it on their code. We teach them these basic things by asking them write games like Tetris, Ping Pong etcRESTfulhttp://java67.blogspot.sg/2015/09/top-10-restful-web-service-interview-questions-answers.htmlnoreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-58204465492084082842015-03-03T10:25:19.053+01:002015-03-03T10:25:19.053+01:00It is obvious that proper , clear and simple comme...It is obvious that proper , clear and simple comments make us understand any code clearly ithttps://www.blogger.com/profile/05949305126710867964noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-29455890507514971882015-01-12T13:46:00.129+01:002015-01-12T13:46:00.129+01:00To further clarify your point on "Code in com...To further clarify your point on "Code in comments", I would suggest that a remedy for that situation is version control. Go ahead and kill that code, you can always go back and see what was there before.Spacemosesnoreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-91544915688960976102015-01-10T12:27:23.761+01:002015-01-10T12:27:23.761+01:00Another thing I noticed: MusicAccessData is a stat...Another thing I noticed: MusicAccessData is a static class, but why? Is it inherently impossible to play two songs at once? If this were a normal class instead of a static class then the class would not be more complex, but it would be more flexible since it would be much easier to stream two songs at once (useful for cross-fades, if you ever want to add those).<br /><br />In general my opinion on making code more flexible and generic is that it should only be done if either you need the extra functionality, or it does not make the code more complex. Adding complexity to add a flexibility that you don't need is a bad idea, but if it is just as much work to build and the code is just as simple, then there is no reason to not be flexible.<br /><br />Also, in general static classes should only be used when this actually makes sense. In most cases normal classes are better, so you should always wonder why you are using static and only use it if there is good reason for it.<br /><br />Do note that I did not look at the code for too long, so maybe there are really good reasons why you made this class static and I just didn't notice it. With all comments anyone gives on code: always wonder whether you are agree, or whether there are further arguments that the commenter (me, in this case) did not realise.Joost van Dongenhttps://www.blogger.com/profile/00569566310604620045noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-30844083700705590882015-01-10T12:23:24.571+01:002015-01-10T12:23:24.571+01:00I didn't look at your code for very long, but ...I didn't look at your code for very long, but a couple of small things that I noticed right away:<br /><br />In Settings.cs starts with a bunch of comments that are so obvious that it would be better not to write those in comments. For example:<br /><br />"//The SettingsLoaded event is raised after the setting values are loaded."<br /><br />The variable name already communicates that.<br /><br />Some of the other comments there are a bit more informative, but could still be removed:<br /><br />"//The SettingChanging event is raised before a setting's value is changed."<br /><br />If you change the event name to "BeforeSettingChanged" then you don't need this comment at all. The main concept of Self Documentating Code is that if you can explain things through code and naming, then you don't need comments. Comments don't raise compile warnings when they are wrong, so comments should only be used when they are actually useful. If possible, clearer code is preferable over comments (or both if needed, of course).Joost van Dongenhttps://www.blogger.com/profile/00569566310604620045noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-64451873074850189362015-01-09T19:24:23.486+01:002015-01-09T19:24:23.486+01:00This is a really good blog and I did send it to on...This is a really good blog and I did send it to one of the interns on my team. Before I had even seen this blog, I basically told him the same thing about what it takes to be a good coder/developer. Consistency is the main thing and I've read a log of code in my career as much as producing code for others to maintain. The thing I noticed most is reading through a lot of crap that makes no sense or are very hard to figure out. Good code is very easy to follow and does not require very much thought process to figure out. When code is formulated, I learned a long time ago from one very intelligent senior developer (while I was a junior), that a line of code should be a singular execution. If a line of code contains multiple execution, it requires the mind to wander and the person to figure out what that line of execution is doing. Also, time and time over the years, you hear others expressing simplicity in implemenation. How true can that be, but it is hard to do than it sounds. To keep things simple, you definitely have to do just that - keep each line of code simple and self documenting. You can document the hell out of the code you want, but if the line of code still doesn't make sense and requires a huge amount of comment, it means that the code should be re-written to make it more simple.<br /><br />As for huge classes, I really don't agree on limitation on the size of any code. Like what the blog has stated, it is impossible to enforce the size of a function and class length to 50 lines or less for methods or 500 lines for classes. The best ways to look at it is to make things simple and make sure a method does only one task and not multiple tasks. The method can be unit tested this way. The unit of code can be a big as you want or as small as you want; and the smallest unit of code is a one line of code, which can be tested. For classes, an intern or a junior developer is likely not going to be able to do this very well or at all in terms of true object orientation. This takes time and experience until that concept is shown over the course of several projects. This is because OO's practicality is transpaarent in a framework and not developed by anyone other than the architect or a senior tech lead. I've seen in so many projects that even senior developers often use static global implementations rather than true OO for code re-usability. This is a bad approach as it is simple and direct; however, over time, you see similar code popping up in different files across the whole system.<br /><br />I totally agree with developing a good sense of coding with consistency through self discipline and good mentoring. It is important for any senior developers to train the intern and junior developers early and make sure coding standards are adhered at all times. It would be totally wrong to either through the person to the fire immediately leave the person to learn things on his/her own. It is also wrong to also ignore the intern and give that person nothing to do during the whole term. I just want to mention these is because I know some companies do that kind of crap and it makes no sense except to claim research grant money from the government.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-22691182889597825442015-01-08T15:01:14.359+01:002015-01-08T15:01:14.359+01:00I agree that with the right habits and skills one ...I agree that with the right habits and skills one writes much better code than without. For example, I personally try to write code cleanly right away, so that I do not need to do a cleaning step at the end.<br /><br />However, refactoring is still sometimes optional. We had a case last week where a class had grown beyond 1000 lines of code and we expected it to grow further. All the code in the class was clean and nice, and the class had a clear purpose. Yet at some point a class just becomes too big to handle and you need to split it. This splitting is extra work (in this case at least a day because the split is also a real restructuring) and fully optional. Good habits could not have avoided this because we didn't know we were going to nee this many features there when we first made that class.Joost van Dongenhttps://www.blogger.com/profile/00569566310604620045noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-66484214732131803232015-01-08T14:57:42.477+01:002015-01-08T14:57:42.477+01:00To me "habit" is often something the sta...To me "habit" is often something the starts with "discipline". If you discipline yourself to always keep Good Code in mind, then at some point it comes automatically and then it is a habit.Joost van Dongenhttps://www.blogger.com/profile/00569566310604620045noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-86151757631332854282015-01-07T17:29:33.002+01:002015-01-07T17:29:33.002+01:00Google SOLID principles in software development. ...Google SOLID principles in software development. There's no good reason for any method to be that long. If you're a hobbyist and don't care then I suppose it is your choice but if you are a professional or expect anyone else to work on your code then you practice is very bad.<br /><br />As Fowler states, we write code for other developers, not for computers. Dale Phttps://www.blogger.com/profile/17369177948655549314noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-41223982358260796932015-01-07T17:22:58.069+01:002015-01-07T17:22:58.069+01:00old commented code never has value. That's wha...old commented code never has value. That's what version control is for. No commented out code should ever be checked into the main branch or trunk. It's ok, I supposed, in your working branch but no further.Dale Phttps://www.blogger.com/profile/17369177948655549314noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-8101439737795823842015-01-07T17:19:28.725+01:002015-01-07T17:19:28.725+01:00I disagree that job demands and time pressures or ...I disagree that job demands and time pressures or schedule excuse writing bad code. When you know how to write good code and writing good code is your habit then writing good code is always faster than writing bad code. Writing unit tests is always faster than not writing unit tests.<br /><br />When developers write bad code because of pressure and schedule it is the developer's skills that are the cause, not the schedule. Needing to update your skills is not a bad thing so please don't get defensive when I say this but needing to update your skills and not updating them is a bad thing - and it's indefensible so no worries about readers getting defensive on that point.<br /><br />So, even if you've been writing code for 25 years, if you are writing bad code because of tight deadlines, get Fowler's Refactoring, read it cover to cover at least twice, and start practicing turning your bad code into good code - at home, and not just at work, until you find it easier to write good code than it is to write bad code.Dale Phttps://www.blogger.com/profile/17369177948655549314noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-75412521967878258802015-01-07T17:03:31.531+01:002015-01-07T17:03:31.531+01:00Overall, let me say I agree with this article but ...Overall, let me say I agree with this article but rather than self-discipline, I think it is a question of habit. Is that the same as self-discipline? Perhaps; it depends on point of view, I suppose. <br /><br />I always teach developers who have problems with writing good code to follow Fowler's Refactoring. Proper refactoring, as Fowler describes, allows developers to be productive while learning to be better OO programmers. Over time, you have to refactor much less because you think to yourself, "If I type this this way now, I just have to refactor it in 5 minutes." You soon find yourself stopping the bad code and writing so you don't have to refactor in the first place. Keep writing code but keep improving the code you already wrote and the code you're writing now by practicing and repeated refactoring until you find you're refactoring less and less.Dale Phttps://www.blogger.com/profile/17369177948655549314noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-37409766995080667312015-01-07T16:54:04.230+01:002015-01-07T16:54:04.230+01:00400 lines seems arbitrary. Classes need to do wha...400 lines seems arbitrary. Classes need to do what it is they need to do. I agree that few classes approach 400 lines but lines-of-code should not be the criteria for class size, purpose and function should be. If you keep your classes focused on the object they represent then lines of code will take care of itself.<br /><br />Method size, on the other hand, I do generally set line limits as a guideline because it makes me focus on keeping my methods single-purpose. Landscape screen is generally too big. In the old 24x80 green-screen days, a screen size was a good limit. Not only did it allow you to see the entire method, it kept them small enough to allow you to easily follow the flow. A method that fills a full landscape screen today still is likely doing too much and has too much complexity to quickly comprehend. Of course, if the single purpose actually does take even more than the full screen then that's what it takes - I just very, very, rarely ever see a single-purpose method that takes that much space - especially if refactored to make it self-documenting and easily read and understood.Dale Phttps://www.blogger.com/profile/17369177948655549314noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-87421363772414460492015-01-07T12:48:23.926+01:002015-01-07T12:48:23.926+01:00Am one of those young programmers interesting arti...Am one of those young programmers interesting article. Check out an application 've been building on and tell me what you think http://mbithy.blogspot.com/2014/12/music-sounds-better-if-you-made-player.htmlAnonymoushttps://www.blogger.com/profile/16181457750681376265noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-16319539888000100252015-01-07T05:45:19.747+01:002015-01-07T05:45:19.747+01:00Chris, on you 2 points:
With comments, I hope you ...Chris, on you 2 points:<br />With comments, I hope you use some type of comment identifier so that you can find all those comment blocks that might need removing, such as //TODO or //REMOVE<br /><br />With class size, size might not matter but high cohesion does. A class' methods must be relevant to that classes purpose. Or if you still code in a non-OOP language(script or Cobol), methods in a file must be relevant to the purpose of that file. <br />I once saw a Cobol file that was 30k lines, all relevant to the file name.<br />So if you call a class/file "Admin", it doesn't mean you put all administration methods for an enterprise into that class/file.<br />What it means is that your naming convention is incorrect as it is not specific enough to be able to break out the various "Admin" methods.<br />As far as function size is concerned, atomicity is important. So ensure a large method only has one purpose. A easy mistake to mix the manager code with the worker code. Try to identify which is which. Manager code and worker code really belong in two different classes.<br />If the method size is getting large ( > 50 lines), then examine the code to see if parts can be refactored into smaller methods. Candidates are code blocks in loops or branching code(if/else or Switch/case). <br />Large methods can also have logical breaks so that code between these logical breaks can be broken out in separate methods, or even separate classes.<br />That is what Refactoring is about. <br />Remember, the general rule is small is best as it will be more manageable and lead to class/method reuse.Anonymoushttps://www.blogger.com/profile/13916599170938757220noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-10495282904748052622015-01-07T05:31:54.948+01:002015-01-07T05:31:54.948+01:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/13916599170938757220noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-86256463078100803972015-01-07T05:08:54.210+01:002015-01-07T05:08:54.210+01:00Joost, so you guys at Ronimo talk to each other in...Joost, so you guys at Ronimo talk to each other in Dutch and code in English? If that is the case, then that really sows how Software is the total idea/implementation and Code(English) is just syntax in a file.Anonymoushttps://www.blogger.com/profile/13916599170938757220noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-64662731832533730032015-01-07T05:00:38.924+01:002015-01-07T05:00:38.924+01:00As Joost said, I wouldn't get a junior program...As Joost said, I wouldn't get a junior programmer or new starter to fix a master programmers bugs. That would only lead to confusion. Besides, the master programmer must fix their bugs and fix them early. Junior programmers or new starters ought to start at either the top of the stack(front end) of the bottom of the stack(DAL & database) and be educated to the more complex middleware. Of course Interfaces and TDD for these must be written firstAnonymoushttps://www.blogger.com/profile/13916599170938757220noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-4431003236455142012015-01-07T02:35:36.347+01:002015-01-07T02:35:36.347+01:00any of that, but learn new things and be different...any of that, but learn new things and be different,sandeephttp://onlinetutorialsplus.blogspot.in/noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-73941421940696094542015-01-07T01:56:00.465+01:002015-01-07T01:56:00.465+01:00If code is commented out, it is not needed anymore...If code is commented out, it is not needed anymore. Therefore, you're safe to delete it. If you want that code back at a later time, use source control. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-18975549216275319082015-01-07T00:07:34.878+01:002015-01-07T00:07:34.878+01:00What if the way you check is not a substring any m...What if the way you check is not a substring any more?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-87195556576059695962015-01-06T23:49:20.500+01:002015-01-06T23:49:20.500+01:00Very interesting indeed :DVery interesting indeed :DJoris van Leeuwenhttps://www.blogger.com/profile/07803717077291067452noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-70518039423480767842015-01-06T21:16:32.066+01:002015-01-06T21:16:32.066+01:00Nice post I agree. Nevertheless, I would like to e...Nice post I agree. Nevertheless, I would like to excuse two "bad" habits:<br /><br />Old commented out code can stay until I'm convinced the new code has proven to be better, until it is not needed anymore, or until I forgot why its there (whatever happens first). Hopefully it gets removed fast.<br /><br />Size is not an issue. Clearness is. Function-size becomes an issue only when clearness suffers, or function-headers are scrolled out of view. For modules, coherency matters and not the number of functions and certainly not the size.Chris Jacobihttp://cjacobi.comnoreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-87552645613877400102015-01-06T20:37:08.880+01:002015-01-06T20:37:08.880+01:00Ah, yes, thanks, fixed! :)
(Surprising that no on...Ah, yes, thanks, fixed! :)<br /><br />(Surprising that no one mentioned this before with over 100k views on this one blogpost!)Joost van Dongenhttps://www.blogger.com/profile/00569566310604620045noreply@blogger.comtag:blogger.com,1999:blog-3064325214589649535.post-16053488786154123862015-01-06T20:34:35.132+01:002015-01-06T20:34:35.132+01:00Indeed, over splitting is also a problem and resul...Indeed, over splitting is also a problem and results in lasagne code (the opposite of spaghetti code). I actually wrote a post with a really nice example of crappy lasagne code a couple of years ago:<br /><br />http://joostdevblog.blogspot.nl/2012/05/programming-with-pasta.html<br /><br />400 lines per class sounds very reasonable though, I wouldn't call that "over splitting". :)Joost van Dongenhttps://www.blogger.com/profile/00569566310604620045noreply@blogger.com