I think reasonable people can disagree on the details here--I think the names I chose were "good enough" and would be understood by Clojure programmers familiar with the standard data structures and core functions. I should point out that some of these names are conventional in Clojure land, for example "idx:" https://clojuredocs.org/clojure.core/map-indexed, https://clojuredocs.org/clojure.core/amap, etc.
DD 2014-12-13 15:00 GMT+09:00 Philip Schwarz < philip.johann.schw...@googlemail.com>: > > Hi David, > > >> a style like I used in my solution which aims for readable conciseness > > > When I first looked at your code, just quickly scanning it, I felt that it > was nice and concise, but I find parameter names like 'len' and 'idx' terse > rather than concise. > > In Venkat Subramaniam's words (in Functional Programming in Java > <https://pragprog.com/book/vsjava8/functional-programming-in-java>) > > *Does concise just mean less code?* >> Concise is short, devoid of noise, and boiled down to its essence to >> convey the intent effectively. The benefits are far reaching. >> Writing code is like throwing ingredients together; making it concise is >> like turning that into a sauce. It often takes more effort to write concise >> code. It’s less code to read, but effective code is transparent. A short >> code listing that’s hard to understand or hides details is terse rather >> than concise. > > > I think 'len' and 'idx' are terse (fewer characters), but not concise. > Every time I read them I can't help translating them into 'length' and > 'index'. This is annoying, especially with 'idx' (with 'len' it is not too > bad). This translation process is somewhat similar to what Robert Martin > calls mental mapping (in Clean Code > <http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882> > ): > > >> *Avoid Mental Mapping*Readers shouldn't have to mentally translate your >> names into other names they already know... > > > Philip > > On Saturday, 6 December 2014 13:36:47 UTC, David Della Costa wrote: >> >> Hi Philip, >> >> I read your message and immediately wanted to try it myself--I intended >> to leave it at that but I realized I would be remiss if I did not give you >> a little bit of feedback based on my experience. I should add that I was >> kind of fast and loose with my solution (that is, I didn't really read the >> instructions), but it does print out the diamond shape according to what I >> saw in the blog post examples. >> >> First of all, here's what I came up with: >> >> https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9 >> >> As you said, you weren't looking for alternative algorithms and I >> recognize that that's not the point. But there are a few things that I >> think are good and/or common Clojure practice that I think I've >> internalized, and writing out an alternative solution helped me to see them. >> >> - I'm assuming you used a TDD process to write this (correct me if >> wrong--basing that on the articles you linked to), but I think a >> repl-driven process may be more common for working through a problem like >> this--i.e. something you can wrap your head around as a whole and solve >> iteratively. That's not to say I and others don't use TDD in Clojure dev, >> but just that it's also quite common to do a lot of this kind of >> development in the repl. >> >> - you're grouping your side-effecting code w/the code that generates the >> diamond data structure here: https://gist.github.com/ddellacosta/ >> ba7e03951ba1bafd3ec9 >> >> While of course the diamond kata is a bit contrived and the point is to >> print stuff out in the end, it also looks like you are trying to be >> thoughtful about how you structure your code. So I would suggest isolating >> your pure functions from your side-effecting code as a sort of basic >> separation, and avoid monolithic functions like the one I linked to above. >> This gives you the freedom to apply the data structure to other processes >> if need be, rather than having to refactor that code later on as soon as >> you need to do something other than printing to the final diamond data >> structure. That is a more compositional approach that is good to follow as >> part of functional programming practice in general. And otherwise it seems >> like you are following this approach--I think you can see this in the shape >> of your code overall. >> >> - Stylistically, I found your naming conventions to be too verbose, with >> not enough information about the actual input and output--I would prefer a >> style like I used in my solution which aims for readable conciseness, while >> documenting what is going in and coming out of my functions. I assume >> Clojure developers reading my code will have a good understanding of the >> core data structures and functions available to manipulate them, and so I >> want to leverage that as much as possible in how I write and document my >> code. >> >> In fact, at this point I prefer using Prismatic's schema ( >> https://github.com/Prismatic/schema) to document as well as provide >> further safety for my functions, and am of the opinion that Clojure's one >> glaring weakness is its approach to typing--but that's another discussion >> and I recognize this is not necessarily a widely-held opinion. >> >> More generally, I think reasonable people could disagree on naming >> conventions and so I would hesitate to say you're doing something "wrong" >> here--I would rather say: the more Clojure code you read the more you'll >> get a sense of how people tend to write. You'll figure out what you want >> to adopt in your own style, and what Clojure devs are going to expect. >> >> - I don't want to get too deep into the algorithm itself but I think you >> would find it more natural to work line by line vs. the way you constructed >> blocks and flipped them right/left, and you'd have less code overall. I >> will boldly claim that my solution may be closer to how other developers >> familiar with Clojure (or functional programming in general) may approach >> it--not that I'm claiming it's the best approach. I do think it is more >> concise without sacrificing readability (which is subjective, I fully >> appreciate). >> >> - I don't know if I've ever once used a main function, and you don't see >> them in libraries, certainly. But that is minor--there's no reason *not* >> to use it, just that I wouldn't expect to see it. >> >> I hope this is useful feedback--good luck in your journey and enjoy >> Clojure! >> >> Dave >> >> >> 2014-12-06 19:48 GMT+09:00 Philip Schwarz <philip.joh...@googlemail.com>: >> >>> Hello, >>> >>> can you please review my first solution to the diamond kata [1] and tear >>> it to bits: let me know all the ways in which YOU would improve the code. >>> >>> I am not so interested in a better algorithm for solving the kata. I am >>> learning Clojure and what I want to know is what YOU would do to make the >>> code more readable/understandable/maintainable, or just to make it >>> follow Clojure idioms and/or conventions that YOU find effective, or to >>> follow a coding style that YOU find more effective. >>> >>> Thanks, >>> >>> Philip >>> >>> [1] https://github.com/philipschwarz/diamond-problem-in-clojure >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
