tag:blogger.com,1999:blog-37274183.post894676098498355940..comments2024-03-14T09:39:31.551+02:00Comments on Java: Developing On The Streets: Shorter is Better?Anonymoushttp://www.blogger.com/profile/15900841850889743147noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-37274183.post-71730682396204206962008-12-06T16:23:00.000+02:002008-12-06T16:23:00.000+02:00Andreas,Maybe it's engineered, but not in the usua...Andreas,<BR/><BR/>Maybe it's engineered, but not in the usual sense. It is code that was written at a Coding Dojo that I attended. I didn't just invent it. I really saw it getting written and evolving. On the other hand, you're right that it is not something that I took from production code.<BR/><BR/>Which makes me wonder. How would the two fragments look like if we let them evolve to handle every n?<BR/><BR/>Like your solution though.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-1051877506058621602008-12-05T19:03:00.000+02:002008-12-05T19:03:00.000+02:00The example looks pretty engineered to prove a poi...The example looks pretty engineered to prove a point, that is, make 13 the maximum so that the computation of X/V works. (And thereby relying on ascii as charset.)<BR/><BR/>Conciseness is not compression by using any way to make the code shorter, it's about expressiveness and removing redundancy. Like factoring out the returns.<BR/><BR/>And who spends time in a debugger? :-) I usually find prints in the code easier and faster than getting a program to the state I want in the debugger.<BR/><BR/>Besides, first thing to boggle the average programmer is the use of recursion instead of loops.<BR/><BR/>And the easiest solution for this exercise is:<BR/>function toRoman(n) { return { "", "I", "II", "III", "IV", "V", "VI", "VII", "VIII", "IX", "X", "XI", "XII", "XIII" } [n]; }Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-24791996138865274912008-12-05T15:18:00.000+02:002008-12-05T15:18:00.000+02:00Martin, your comment motivated me to write a post ...Martin, your comment motivated me to write a post whose title is indeed <A HREF="http://javadots.blogspot.com/2008/12/longer-is-sometimes-better.html" REL="nofollow">Longer is sometimes better</A>. <BR/><BR/>Thanks.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-90548096624505050312008-11-29T01:08:00.000+02:002008-11-29T01:08:00.000+02:00Martin: I couldn't agree more. I guess there is a ...Martin: I couldn't agree more. I guess there is a justification for a "longer is sometimes better" post :)<BR/><BR/>One quick example is: "if(...) x = a;"<BR/>It is so much easier to debug such a statement if its split across two lines - You can visually see whether the condition holds. No need to guess (after the fact) by inspecting x's value.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-61312906180564265652008-11-28T16:51:00.000+02:002008-11-28T16:51:00.000+02:00I think that if you write short and clear it is th...I think that if you write short and clear it is the best. <BR/>if people are writing trenary for a while they will know how to read it. <BR/>I don't want that a person will be able to read my code, I want a fellow programmer to read it.<BR/>its about conventions. <BR/>and a short convention is generally better I think, because its easier to read!<BR/>not religiously of course.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-31600563162781195552008-11-28T16:29:00.000+02:002008-11-28T16:29:00.000+02:00I also found out, that debugging is often better w...I also found out, that debugging is often better when splitting over different statements and lines.<BR/><BR/>And as I usually spend also a while debugging the longer and clearer code reduces my debugging time.Martin Wildamhttps://www.blogger.com/profile/10078822365635360301noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-55013710910184231472008-11-28T11:13:00.000+02:002008-11-28T11:13:00.000+02:00jv, Stephan, Gyorgy: I absolutely agree. I think i...jv, Stephan, Gyorgy: I absolutely agree. I think it boils down to the fact that we can measure length, but we cannot measure readability (as jv said, it is a subjective issue). <BR/><BR/>This leads to length being used, too often, as a quality indication: "hey, we have numerical values, we can shove them into a spreadsheet and look at some nice graphs!". Too bad.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-53643533268426101902008-11-28T08:58:00.000+02:002008-11-28T08:58:00.000+02:00Readability always suffers when you compacting the...Readability always suffers when you compacting the code...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-37274183.post-38698813188816194062008-11-28T08:25:00.000+02:002008-11-28T08:25:00.000+02:00I believe in more readable is better, not shorter ...I believe in more readable is better, not shorter is better. Sometimes people confuse these two things.<BR/><BR/>You can't get much shorter than K, testing prime in the K language:<BR/><BR/>{&/x!/:2_!x}<BR/><BR/>Peace<BR/>-stephan<BR/><BR/>--<BR/>Blog at http://www.codemonkeyism.com/Stephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-85418434997764224462008-11-28T01:49:00.000+02:002008-11-28T01:49:00.000+02:00It's a matter of taste as well actually. Using the...It's a matter of taste as well actually. Using the ternary operation (and formatting it properly) leads to a code that's leans towards functional programming and are appreciated to those who are used to such. The longer one however, I would say, is "clearer" to imperative programmers.jvhttps://www.blogger.com/profile/07219432575271252157noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-86669015853436054982008-11-25T12:53:00.000+02:002008-11-25T12:53:00.000+02:00Hi Itay, I think we agree. Writing correct and cle...Hi Itay, <BR/><BR/>I think we agree. Writing correct and clear code is the minimum requirement from a programmer - no one should sacrifice that for brevity. Too often people try to be too smart for their own good, which is what you wanted to demonstrate, I think. <BR/><BR/>Nonetheless, true art of programming is IMO in keeping the code small and succinct, in addition, but not at the expense of other factors.Yardenahttps://www.blogger.com/profile/15649241856669571499noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-8604536313625163162008-11-25T12:15:00.000+02:002008-11-25T12:15:00.000+02:00Yardena,I am not saying that the compact form is a...Yardena,<BR/><BR/>I am not saying that the compact form is always more complicated than the longer one. Many compact forms are clearer.<BR/><BR/>However, sometimes an attempt to reduce line count can follow a bad path, ending up with a shorter, but less readable, code.<BR/><BR/>In your version, you (successfully) made the code clearer by breaking each line immediately after the colon symbol. This imposed a consistent visual structure which promotes readability. <BR/><BR/>In doing so you made the code a little longer (line-count wise) since some of these lines could be consolidated, assuming the standard 80 column line width. This gets us back to my point about trade-offs: you want your code to be short but consistent structure, explicitness and other factors are also important.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-81445454369097690732008-11-25T11:29:00.000+02:002008-11-25T11:29:00.000+02:00return (n == 0)? "": (n < 4)...return (n == 0)? "":<BR/> (n < 4)? "I" + toRoman(n - 1):<BR/> (n == 4 || n == 9)? "I" + toRoman(n + 1): <BR/> (n >= 10) ? "X" + toRoman(n - 10):<BR/> "V" + toRoman(n - 5);<BR/><BR/>and you don't have to repeat *if* and *return* 5 times. Also it is clear that you cover all options, unlike your example, which would not compile in Java requiring unconditional return statement in the end.Yardenahttps://www.blogger.com/profile/15649241856669571499noreply@blogger.com