Android Question Are there size limits for subs?

Discussion in 'Android Questions' started by schemer, Jan 23, 2015.

  1. schemer

    schemer Active Member Licensed User

    I am going to try to rewrite a VB app using B4A and want to know if there are any limits on the amount of lines in any one subroutine? The reason I ask is I remember in VB there was a limit where I had to continue a subroutine and make it in 2 parts. The other reason is because my app has a lot of info hard coded into many subs as opposed to using a database which I am still in the process of learning. :confused:
    Thanks,
    schemer
     
    nikolaus likes this.
  2. NJDude

    NJDude Expert Licensed User

    Read THIS post.
     
  3. schemer

    schemer Active Member Licensed User

    I just checked and I have about 1200 lines of code in a few different subs. After reading the link you posted I realize I have some work to do but is that correct as one poster mentioned that 20 lines for a sub should be maximum? If so, I would need to make 6o subs just for this one sub and I have more than one that are large. So what is the true maximum in lines as I don't know how to figure what 64kb (JVM bytecode) for a single sub means in lines.
    Thanks,
    schemer
     
  4. ivan.tellez

    ivan.tellez Active Member Licensed User

    There is not a "Lines" Limit, the limit is the code size as a whole a Line could be really small (X=2) or really really long.

    But the fact is, the bigger the sub, the slower it is on java.

    Also, if you have methods with more than 50 lines, you are considered a really bad programmer. (talking about hardcoding data on the sub)

    Its a really bad thing to have Data hard coded. you have to use serialization/deserialization of data structures so save the data on files or Databases.
     
    Last edited: Jan 25, 2015
    Peter Simpson, WAZUMBi and schemer like this.
  5. schemer

    schemer Active Member Licensed User

    Hi ivan,
    That is good my methods are reasonably sized but I am probably considered a bad program for one reason or another. :p My subroutines are the biggies! My program started out small and grew and grew and I wished I had used a database but wasn't learning that part as quick as I needed to at the time. I am still learning. o_O This is my first Java stuff although I have messed with Javascript in web pages but mainly the easiest of it. As far as my data being hard coded it was because of two reasons. I didn't know database programming and I didn't want the data stolen for reuse as it took a lot of work to get it. That said, my data will still be in a sense "hard coded", but in a db, and will be read and manipulated (numbers only), and output by printer. I can see some good expansion for the use of a database though. I posted some SQLite questions in another thread so I guess its best to talk db stuff there.
    Thanks,
    schemer
     
  6. Informatix

    Informatix Expert Licensed User

    Why? Where did you read that? It seems to me that's the contrary. Splitting a sub in many subs is slower due to the overhead of each function call.

    Then I know a lot of professionals that are really bad... including me.
     
  7. ivan.tellez

    ivan.tellez Active Member Licensed User

    That really deppends. On advanced programs its somethimes important to have large subs.
    But In this case I was talking about hardcodding all the data in the sub.
    Also, there are some "best practices" recommending avoiding huge classes and huge subs to comply with Testability, Cohesion, Coupling and Understandability.
    (Note that this is a recomendation, not mandatory, and in some special cases is not aplicable)

    I thought the same when i read that, I dont really remember the source, but states that the JIT will not compile subs larger than 8kb (JVM bytecode), so the the code runs slower. (Could be wrong, Maybe some benchmarks with huge subs and Splitted ones could be useful.)
     
  8. ivan.tellez

    ivan.tellez Active Member Licensed User

    Actually, Java is to Javascript the same as Ham is to Hamster, or Carpet to a Car. While the two have similar names, they are really two completely different programming languages/models/platforms, and are used to solve completely different sets of problems.

    You can use encryption to store sensitive data on the file or in the Database.
     
  9. Peter Simpson

    Peter Simpson Expert Licensed User

    Why have such big subs?
    Infact you should be using CallSub(Null, SubName) rather than reaching anywhere near 64,000 characters in a sub. Plus jumping out to call sub's makes for easier reading back of code (well I think so anyway).

    You should not really be hard coding data directly into your apps, you should either be using some sort of database (SQLite in your case) or maybe even a .dat file.
     
    Last edited: Jan 26, 2015
    ivan.tellez likes this.
  10. Troberg

    Troberg Well-Known Member Licensed User

    Big subs happen, and, occasionally, there is a good reason for it. I have made some very large subs a couple of times where I've felt it was motivated:

    * A large calculation (millions of values in, thousands of values out and lots of math in the middle). I could have broken it up into several subs, but that would have required passing 8-12 parameters, most of them multidimensional (up to 6) arrays of types. It really wouldn't have done anything for clarity, so I let it be large.

    * A search engine for a database frontend. Basically, I made a code generator, which analyzed the database, produced most of the gui and then generated SQL statements based on what the user had selected. The code generated by this generator had some very large subs, as it more or less mirrored the database structure when building gui and SQL statements. However, as it was generated code that needed no manual touch, I didn't bother.

    * An AI for a game. Lots of alternatives to try out, deeply nested. I tried a recursive solution, and the stack promptly exploded, so in the end, I put it all as deeply nested loops in one sub instead.

    However, for readability, I'm pretty careful to comment and use regions a lot, to bring some structure to it. I also always go back and see if there is room for refactoring, if bits can be broken out or the code can be partitioned in a reasonable way.
     
    thedesolatesoul likes this.
  11. Informatix

    Informatix Expert Licensed User

    I do the same.
    There's no rule of thumb for the length of code. An AI is a typical case where you can have a very long sub because of the size of the decision tree (the number of conditions that can change a value/state).
     
  12. Peter Simpson

    Peter Simpson Expert Licensed User

    But subs touching 64k @Troberg. I've developed an intelligent search engines for a large UK firm with some long complicates formulas and subs, but none of my subs are near 64k, nowhere near.

    I will not lie to you. I usually write huge routines and comment them like you do. Once completed though, I'll brake it up into smaller subs if it's logical to do so :)

    Hey, each to their own though right :D. Anyway @schemer main problem is that he is hard coding huge data into the actual source code when IMO a database (preferably SQLite) should be used, but that's only IMO so please don't bother arguing with me, as it's only my opinion. But as I just said, each to their own especially on sub sizes, there's no written rules to sub sizes.
     
    Last edited: Jan 26, 2015
  13. Troberg

    Troberg Well-Known Member Licensed User

    My search engine was made by my code generator. The code generator was fairly small, mostly a scanning of the database structure, then recursively selecting templates and inserting data into them. Simple enough, but the resulting code was huge.

    On the other hand, I never needed to touch the generated code, and if the database changed, I just generated it again.
     
    Peter Simpson likes this.
  14. Informatix

    Informatix Expert Licensed User

    I just checked what was my longest sub. 882 lines with comments (IA code calling many subs, so the whole code is over 2000 lines). This is a very very long sub from my point of view, which is not splitted because it is more readable like this (it's very linear) and it takes 45 Kb. So 64 Kb is huge indeed.
     
    Peter Simpson likes this.
  15. Peter Simpson

    Peter Simpson Expert Licensed User

    Say whaaaaaaaaaaaaaaaaaaaaaaaaaaaat, 25Kb ;)

    I do completely understand where both yourself @Informatix and @Troberg are coming from with linear coding. I personally sub out routines at are 100% percent correct and that will not change, thus making the main sub smaller and easier to read for me.

    @schemer you said that you're learning databases, that really is the best option for you :). Once you've learned about db's, you'll find everything a lot easier to manage.
     
  16. schemer

    schemer Active Member Licensed User

    Well I am glad to see some discussion here. :) My large subs are over 2000 lines! I copied the code and comments into NotePad++ and removed the spaces to figure that out. But they are just SELECT CASE statements where I loaded my data into various places after a main item was selected by the user. They are lines of data though. I am looking forward to working with my db as I finish creating it and I am 100% sure it will make my programming days ahead much easier than it has been in the past. In the past I had to keep synchronized 6 subroutines to keep the related data in line with the main one being alphabetized! Every time I needed to add an item into the main sub, it was a whole lot of work. I had comments that were basically numbers in increment of 10, so if I had to make an insert, there was room. But then I had to renumber all of the comments and corresponding subs so I could keep the data in sync. Big pain. The db will take care of this for sure. Live and learn. I am alive and I am learning. :D
    Thanks,
    schemer
     
    Last edited: Jan 26, 2015
Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice