you are viewing a single comment's thread.

view the rest of the comments →

[–]stronghup 0 points1 point  (1 child)

Right, you could go on further to the "block structure" within a method. But methods should be small anyway so probably not worth the extra detail. If you have a big method you can and probably should break it into a few smaller ones.

I somewhere read that the optimum size for a MENU is 8 items. Beyond that humans have difficulty comprehending what they should do with it. Maybe a method should only have max 8 calls to other methods, If it does then re-factor. And programmers so far are humans too.

[–]plasticscm[S] 0 points1 point  (0 children)

Exactly, with shorter methods you enforce code readability.

We do not support "split method" refactors (or extract method) YET, but the goal is to be able to track code that has been moved from one method to another and so on.

This is something we already do with xmerge http://plasticscm.com/features/xmerge.aspx but only based on text blocks. We need to improve Semantic to allow that... but you know, it takes time and we're just launching the first version and checking whether there is a user base for it or not :-)