I agree as well. Lets start re-factoring and then make sure that moving forward that is the way we keep it.
On Fri, Apr 22, 2011 at 9:44 AM, Jordan Wilberding <[email protected]> wrote: > I completely agree on all points. I think although not required, having > specs for internal functions creates a more resilient code base that is less > prone to errors. It forces you to think through the functions and allows us > to use automated quality tools. > As for exporting types. This needs to be required, without exception. I > don't see any scenario where you export a function without all of it's > associated types being exported as well. > Thanks! > JW > > On Fri, Apr 22, 2011 at 9:47 AM, Eric Merritt <[email protected]> > wrote: >> >> Guys, >> >> The modules we have in erlware_commons, ec_semver, ec_strings, etc. >> have great public APIs, but none of the internal functions have specs. >> Yes we have said they are optional but encouraged and thats true. >> However, not having them really interferes with dializers ability to >> find issues and makes the code quite a bit less understandable. Its >> less important in these projects where an individual owns them >> (ciconia, sinan, etc) however, I think its pretty important for >> dedicated libraries like commons. So, when you are reviewing code, >> push back at least a bit, if you don't see specs on the majority of >> the functions. The developer may have a good reason for not having >> them, and if they insist on being lazy its ok (its optional after all) >> but a little bit of push back should increase our quality here. >> >> Another big deal, is none of our stuff exports types and they should, >> especially modules that actually implement types like ec_semvar, and >> ec_strings. Exported types *are* part of the public api and if your >> module has a distinct type you should be exporting it. I will try to >> grab some time to fix this stuff this weekend but, going forward lets >> try to have it in there. It is better to get in the habit of having it >> there then having to constantly go back and add it. >> >> Eric >> >> -- >> You received this message because you are subscribed to the Google Groups >> "erlware-dev" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/erlware-dev?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "erlware-dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/erlware-dev?hl=en. > -- Martin Logan Erlang & OTP in Action (Manning) http://manning.com/logan http://twitter.com/martinjlogan http://erlware.org -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
