Reply to thread

Message: [QUOTE="Alan Gauld, post: 1731955"] Do you have any objective evidence to suggest that this is true? What proprtion exactly is due to this? The reason I ask is that most of the long functions I have seen have been products of the algorithm being implemented. If an algorithm takes 300 lines to express it should be expressed as 300 lines. I have *never* seen a long function that is the result of a programmer avoiding using user vocabulary! Equally I see no evidence whatsoever to suggest that users express requirements in short chunks - usually the opposite, we get presented with long complex prose describing a convoluted business process and the programmer has to split that into its natural chunks during analysis! If anyone has done any research to connect long functions with ignoring of user language I'm unaware of it and would be most interested in seeing it. Not necessarily(*), but I would agree that usually they are, but at the lower levels the solution space may bear no resemblance to the problem domain at all! (*) For example where the solution architecture is based on a mathematical technique which would be impractical in a manual business process but is entirely practical using computing power. As a somewhat dated example - the processes used in computer crytography for example being entirely different to those used in manual cryptrography. There will be some concepts in common but many will be entirely novel. In the general case I agree completely but a blanket statement that it is always true is absurd. There are many cases when a programmer is dealing with issues that simply don't arise in the human scenario. Anonymous functions are often used in scenarios where a name is meaningless. Even in business processes it is not unusual to find processes with names like JDI(Just Do It) or DWN (Do Whatever's Necessary) to deal with extraordinary scenarios. (Although ironically these are rarely the ones which require anonymous funtions in code!) Ah, we do agree at this level. So your point only applies to "high level" functions. The issue then becomes one of deciding at what point the solution and problem domains separate. Usually, but not always. Or often highly generic names which are best implemented using higher order programming techniques involving anonymous names. Again, in general I agree. But if the name is f and it is only used for as long as it takes to convey a single use function into the argument list of another function then I find the naming to be of little or no value. I'm not sure I agree there. It happens in the real world all the time. (Consider Internet Chat Rooms! Many users there desire anonymity while using a name which may not be their identity. Indeed they achieve anonynimty through their false identity!) I agree that good names are a good thing and time should be spent considering appropriate ones but... Bad naming is rarely if ever the reason for failed projects. It may contribute by slowing down testing or integration and thus causing estimate failure (the most comon reason for failed projects) but naming alone is not enough to cause a failure IMHO. Insofar as the problem domain is reflected in the solution space I agree. Certainly a programmer who does not understand the vocabulary of his end user is unlikely to create good solutions. Naming is important where a name aids understanding. If a name is just there as a marker it serves no purpose. I agree that this rarely happens at a high level in the design but I think it happens at a higher level that you suggest. Not often, but often enough to prevent blanket assertions being made. Alan G. Author of the Learn to Program website [URL]http://www.freenetpages.co.uk/hp/alan.gauld[/URL] [/QUOTE]

Verification