Author Topic: Library section  (Read 9895 times)

0 Members and 1 Guest are viewing this topic.

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Library section
« on: August 25, 2018, 03:56:03 pm »
I noticed there is no dedicated area for libraries as there was on [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]. I like the way the samples area is done with only the librarian having access to changes.

Would it be possible for a library area to be created much the same as the samples area but with a twist? Owners of libraries could post and modify but other users would not be able to post replies? Library discussion could be held in the standard forum areas instead.

The [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] library section got pretty convoluted over time with posts of code that were not really a library and discussions of other topics other than that pertaining to the libraries themselves. So many of us have functional libraries to share (and in my case update) that it would be nice to have a dedicated section.

Just a thought.
In order to understand recursion, one must first understand recursion.

Offline RhoSigma

  • QB64 Developer
  • Forum Resident
  • Posts: 565
    • View Profile
Re: Library section
« Reply #1 on: August 25, 2018, 04:22:16 pm »
I'd like to see such a Library Section here too, and also like Terry's idea of limited posting access for Lib-Owners only. It would help to keep the Section "On Topic".
My Projects:   https://qb64forum.alephc.xyz/index.php?topic=809
GuiTools - A graphic UI framework (can do multiple UI forms/windows in one program)
Libraries - ImageProcess, StringBuffers (virt. files), MD5/SHA2-Hash, LZW etc.
Bonus - Blankers, QB64/Notepad++ setup pack

Offline odin

  • Administrator
  • Newbie
  • Posts: 92
  • I am.
    • View Profile
Re: Library section
« Reply #2 on: August 26, 2018, 12:07:49 am »
Under analysis.

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: Library section
« Reply #3 on: August 26, 2018, 06:44:43 pm »
Hi
IMHO
It can be a good stuff if well managed...
A) like Terry suggests with no discussion or feedback in the same section,
B) moreover it may be listed specific features to use with code of library
for examples
1. to make it readable 
2.  the convention to write names for variable, CONST , Function, Subroutine, Type Data  to avoid conflict of name if used together with other library of the final QB64user and/or another QB64coder
3. the documentation (DOCs and/or little tutorial)
4. the example code posted can be grouped or easy visible like for now we are doing with InForm, we start thread with [InForm]:

at this moment if I want to use in the same program a library of  Steve and another of Fellippe  I must pray that there is not duplicate of names for functions, subs, constants, variables, labels and so on or I got a mess of errors and/or bugs.

I think that the compatibility among the different libraries is fundamental to let grow QB64 flexisibility. More, it is our interest to have get more power in our code using  specific well suited libraries build for different goals that work well together.

Moreover I think to all those different libraries build by QB64 coders and left at rest because lacking of documentation thought for newbie for that field or that resource. So many efforts launched in the void.
Programming isn't difficult, only it's  consuming time and coffee

Offline RhoSigma

  • QB64 Developer
  • Forum Resident
  • Posts: 565
    • View Profile
Re: Library section
« Reply #4 on: August 27, 2018, 04:42:32 am »
About name conflicts,

I think there should be no problems in *.bm files. These should contain SUBs/FUNCTIONs only, which can be seen as "BlackBox" modules because variable names, labels etc. are local in the scope of SUBs/FUNCTIONs unless they are SHARED. In this case, those variables (and those DIMed or CONSTed in *.bi) should begin with a lib-specific prefix. I think about the syntax Fellippe is using in InForm for all that __UI_.... variables. It could be used for libs as __Libname_...., of course, the same scheme would apply to SUB/FUNCTION names in *.bm files as well, to not end up with 5 different "SaveImage" functions in the future.

However, this is all in the responsibility of the library's autor/owner and should be discussed, before we actually implement it in our existing libraries. All this has otherwise nothing to do with the suggested access features for a Library Section here on the forum.
« Last Edit: August 27, 2018, 04:48:30 am by RhoSigma »
My Projects:   https://qb64forum.alephc.xyz/index.php?topic=809
GuiTools - A graphic UI framework (can do multiple UI forms/windows in one program)
Libraries - ImageProcess, StringBuffers (virt. files), MD5/SHA2-Hash, LZW etc.
Bonus - Blankers, QB64/Notepad++ setup pack

Offline RhoSigma

  • QB64 Developer
  • Forum Resident
  • Posts: 565
    • View Profile
Re: Library section
« Reply #5 on: August 27, 2018, 05:55:19 am »
Another idea, maybe could the above mentioned name conflict thing be implemented directly into QB64, so that it uses different namespaces on the C/C++ level for each included file. I already do such a thing in my QB-StdLibs in its C header files and in the respective DECLARE LIBRARY blocks in *.bi files I use the ALIAS keyword to reference them according to its namespace.

My Projects:   https://qb64forum.alephc.xyz/index.php?topic=809
GuiTools - A graphic UI framework (can do multiple UI forms/windows in one program)
Libraries - ImageProcess, StringBuffers (virt. files), MD5/SHA2-Hash, LZW etc.
Bonus - Blankers, QB64/Notepad++ setup pack

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: Library section
« Reply #6 on: September 07, 2018, 11:44:40 pm »
While sitting here rewriting my Sprite Library RhoSigma's input about name conflicts got me thinking. I've decided to start all the SUBs/FUNCTIONS in my library with double underscore (__LOADSPRITESHEET). Also, any variables SHARED between subs/functions will also start with double underscore (TYPE __SHEET, REDIM __sheet(1) as __SHEET, SHARED __sheet() as __SHEET, etc..)

CONSTants I'm a little torn on though. I suppose I could make them unique enough to have a 99.99% chance of not accidentally being used again (CONST NOTRANSPARENCY = -1). I just don't like the look of a constant starting with double underscore (__NOTRANSPARENCY).

I too like the naming convention Fellippe used in InForm and agree a consensus should be established.

« Last Edit: September 07, 2018, 11:45:58 pm by TerryRitchie »
In order to understand recursion, one must first understand recursion.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Library section
« Reply #7 on: September 08, 2018, 12:29:54 am »
I too like the naming convention Fellippe used in InForm and agree a consensus should be established.

Instead of double underscores for uniqueness (after all, __Xpos is common enough that a conflict can still arise if a user has more than one library loaded), I think a few basic rules for libraries should be adhered to, if we're going to establish semi-formal rules for sharing:

1) Subs/Functions should start with creator initial.  A Steve(tm) library would use SM_ for naming convention.  Sure, there might be more than one guy with the SM initials out there, but if there is, he hasn't posted much here on the forums, and all conflicts with SM_Xpos and TR_Xpos are instantly cleared up...

2) GLOBAL Names should be self descriptive as much as possible.  SM_TextToImage is much easier to understand, remember, and use than SM_TTI, and chances are, it's also more resistant against accidental duplication.

3) COMMON variable names (such as any single digit character) should *always* be LOCAL and TEMPORARY in scope.  Don't DIM SHARED X, Y, I, K, M, ect...  Keep them reserved as temp variables and they should never interfere with another user's variables.

4) Unless NECESSARY, Subs/Functions should never pass values back via the parameter.  Instead of SUB SM_MathJunk (X, Y), values should be passed as SUB SM_MathJunk (TempX, TempY), with the next line reading X = TempX: Y = TempY.  This practice prevents all instances of accidental value corruption.

5) Arrays should be hard indexed.  Don't DIM SHARED Array(10); instead DIM SHARED Array(0 To 10).  This prevents incompatibility if the user has OPTION BASE 1 in effect.

6) Subs/Functions should *always* restore settings before exit.  If your sub needs a _DISPLAY to show text on the screen (such as for a message box), check to see if the user had _AUTODISPLAY on, and if so, restore it on exit.  _DEST, _SOURCE, _BLEND, COLOR, Visible Screen, and lots more *can* be altered while in a sub, but unless that's the intended purpose of the sub, it shouldn't happen in Library code.

7) Useage of Global Flags/Metacommands should be avoided.  DON'T count on DEFLNG A-Z to be set, or OPTION BASE to be 0/1, or $DYNAMIC to be in use.  Once you share a library publicly, you'll run into somebody who has the option set completely backwards of what you always ASSUMED was standard.

************************

And I think that's about my limit on advice for good Library creation, at the moment.  :D
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: Library section
« Reply #8 on: September 08, 2018, 01:33:33 am »
I too like the naming convention Fellippe used in InForm and agree a consensus should be established.
1) Subs/Functions should start with creator initial.  A Steve(tm) library would use SM_ for naming convention.  Sure, there might be more than one guy with the SM initials out there, but if there is, he hasn't posted much here on the forums, and all conflicts with SM_Xpos and TR_Xpos are instantly cleared up...

I like them all except for this one. Instead of using creator initials how about two letters that describe the library, SL_Xpos for Sprite Library, as an example? The reason creator initials may not work is because a creator may use SM_Xpos in more than one library. A programmer using two or more libraries at a time from the same creator may run into variable issues.
In order to understand recursion, one must first understand recursion.

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: Library section
« Reply #9 on: September 08, 2018, 03:16:45 am »
The code below is an example of what I have so far as naming conventions go.

One other thing I think should be added to the list. In your library don't set constants TRUE and FALSE. It's pretty common practice for coders to add the line:

CONST FALSE = 0, TRUE = NOT FALSE

I always make sure to set any boolean truths to -1 for true and 0 for false in my code. I noticed the InForm library set True and False and this may cause issues later on down the road.

Code: QB64: [Select]
  1. '*
  2. '* constants used with SL_LOADSPRITESHEET function
  3. '*
  4. CONST SL_SHEETTRANSPARENCY = -1 '       use sheet's transparency info (.PNG)
  5. CONST SL_SETTRANSPARENCY = 0 '          manually set transparency
  6. CONST SL_NOTRANSPARENCY = 1 '           don't use transparency with sheet
  7. '*
  8. '* type declarations
  9. '*
  10. TYPE SL_SHEET
  11.     inuse AS INTEGER '                  sheet is in use (true / false)
  12.     sheetimage AS LONG '                image handle of sheet
  13.     sheetwidth AS INTEGER '             width of sheet
  14.     sheetheight AS INTEGER '            height of sheet
  15.     spritewidth AS INTEGER '            width of each sprite
  16.     spriteheight AS INTEGER '           height of each sprite
  17.     transparency AS INTEGER '           sheet transparency type
  18.     transcolor AS _UNSIGNED LONG '      transparent color on sheet
  19.     columns AS INTEGER '                number of sprite columns
  20.     rows AS INTEGER '                   number of sprite rows
  21. '*
  22. '* defined arrays
  23. '*
  24. REDIM SL_sheet(1) AS SL_SHEET '         sprite sheet list
  25.  
  26.  
  27. '*
  28. '* main code (for testing)
  29. '*
  30.  
  31. tr3bsheet = SL_LOADSPRITESHEET("tr3bsheet266x266.png", 266, 266, SL_SETTRANSPARENCY, _RGB32(255, 0, 255))
  32.  
  33. PRINT SL_sheet(tr3bsheet).inuse
  34. PRINT SL_sheet(tr3bsheet).sheetwidth
  35. PRINT SL_sheet(tr3bsheet).sheetheight
  36. PRINT SL_sheet(tr3bsheet).spritewidth
  37. PRINT SL_sheet(tr3bsheet).spriteheight
  38. PRINT SL_sheet(tr3bsheet).transparency
  39. PRINT SL_sheet(tr3bsheet).transcolor
  40. PRINT SL_sheet(tr3bsheet).columns
  41. PRINT SL_sheet(tr3bsheet).rows
  42.  
  43.  
  44.  
  45. '######################################################################################################################################
  46.  
  47. FUNCTION SL_LOADSPRITESHEET (filename$, spritewidth%, spriteheight%, transparency%, transcolor~&) '                  SL_LOADSPRITESHEET
  48.     '+----------------------------------------------------------------------------+---------------------------------------------------+
  49.     '| Loads a sprite sheet into the sprite sheet array and assigns an integer    |                     - NOTES -                     |
  50.     '| handle value pointing to the sheet.                                        |                                                   |
  51.     '|                                                                            |                                                   |
  52.     '| Usage : mysheet% = SL_LOADSPRITESHEET("sprites.png", 64, 96, _RGB(0, 1, 0))|                                                   |
  53.     '|                                                                            | - Specifying a file name of a file that does not  |
  54.     '| Input : filename$     - the name of the sprite sheet image                 |   exist will result in the function reporting an  |
  55.     '|         spritewidth%  - the width of each sprite on the sheet              |   error and halting program execution.            |
  56.     '|         spriteheight% - the height of each sprite on the sheet             |                                                   |
  57.     '|         transparency% - type of transparency to apply to sheet             |                                                   |
  58.     '|                          -1 = use sheet's  (constant SL_SHEETTRANSPARENCY) |                                                   |
  59.     '|                           0 = user defined   (constant SL_SETTRANSPARENCY) |                                                   |
  60.     '|                           1 = no transparency (constant SL_NOTRANSPARENCY) | - The constants SL_SHEETTRANSPARENCY,             |
  61.     '|         transcolor~&  - user defined transpareny color of sheet            |   SL_SETTRANSPARENCY, and SL_NOTRANSPARENCY have  |
  62.     '|                         only used when transparency% set to zero (0)       |   been created to be used with this function.     |
  63.     '|                                                                            |                                                   |
  64.     '|                                                                            |                                                   |
  65.     '| Output: integer value greater than 0 pointing to the newly loaded sheet    |                                                   |
  66.     '|                                                                            |                                                   |
  67.     '+----------------------------------------------------------------------------+---------------------------------------------------+
  68.     '| Known Issues: None                                                                                                             |
  69.     '|                                                                                                                                |
  70.     '+--------------------------------------------------------------------------------------------------------------------------------+
  71.  
  72.     SHARED SL_sheet() AS SL_SHEET '                                                 array defining sprite sheets
  73.  
  74.     DIM handle% '       (INTEGER)                                                   handle number of new sprite sheet
  75.     DIM x%, y% '        (INTEGER)                                                   generic counters
  76.     DIM osource& '      (LONG)                                                      original source image
  77.     DIM pixel~& '       (_UNSIGNED LONG)                                            pixel color at x%, y% coordinate
  78.     DIM alpha~& '       (_UNSIGNED LONG)                                            alpha level of current pixel
  79.  
  80.     IF NOT _FILEEXISTS(filename$) THEN '                                            does the sprite sheet exist?
  81.         SL_SPRITEERROR "SL_LOADSPRITESHEET", 106, filename$ '                       no, report error to programmer
  82.     END IF
  83.     IF ABS(transparency%) > 1 THEN '                                                valid transparency setting?
  84.         SL_SPRITEERROR "SL_LOADSPRITESHEET", 108, "" '                              no, report error to programmer
  85.     END IF
  86.     IF spritewidth% < 1 OR spriteheight% < 1 THEN '                                 valid sprite width/height supplied?
  87.         SL_SPRITEERROR "SL_LOADSPRITESHEET", 109, "" '                              no, report error to programmer
  88.     END IF
  89.     handle% = 0 '                                                                   initialize handle value
  90.     DO '                                                                            look for the next available handle
  91.         handle% = handle% + 1 '                                                     increment the handle value
  92.     LOOP UNTIL (NOT SL_sheet(handle%).inuse) OR handle% = UBOUND(SL_sheet) '        stop looking when valid handle value found
  93.     IF SL_sheet(handle%).inuse THEN '                                               is the last array element in use?
  94.         handle% = handle% + 1 '                                                     yes, increment the handle value
  95.         REDIM _PRESERVE SL_sheet(handle%) AS SL_SHEET '                             increase the size of sprite sheet array
  96.     END IF
  97.     SL_sheet(handle%).sheetimage = _LOADIMAGE(filename$, 32) '                      assign the image to the array
  98.     SL_sheet(handle%).inuse = -1 '                                          (TRUE)  mark this element as being used
  99.     SL_sheet(handle%).sheetwidth = _WIDTH(SL_sheet(handle%).sheetimage) '           save the width of the sprite sheet
  100.     SL_sheet(handle%).sheetheight = _HEIGHT(SL_sheet(handle%).sheetimage) '         save the height of the sprite sheet
  101.     SL_sheet(handle%).spritewidth = spritewidth% '                                  save the width of each sprite
  102.     SL_sheet(handle%).spriteheight = spriteheight% '                                save the height of each sprite
  103.     SL_sheet(handle%).columns = SL_sheet(handle%).sheetwidth \ spritewidth% '       number of sprite columns on sheet
  104.     SL_sheet(handle%).rows = SL_sheet(handle%).sheetheight \ spriteheight% '        number of sprite rows on sheet
  105.     SL_sheet(handle%).transparency = transparency% '                                sheet transparency type
  106.     IF transparency% = -1 THEN '                   (constant SL_SHEETTRANSPARENCY)  sheet have alpha channel?
  107.         x% = 0 '                                                                    yes, start at upper left x of sheet
  108.         y% = 0 '                                                                    start at upper left y of sheet
  109.         osource& = _SOURCE '                                                        remember current source
  110.         _SOURCE SL_sheet(handle%).sheetimage '                                      set the sprite sheet image as the source image
  111.         DO '                                                                        start looping through the sheet's pixels
  112.             pixel~& = POINT(x%, y%) '                                               get the pixel's color attributes
  113.             alpha~& = _ALPHA32(pixel~&) '                                           get the alpha level (0 - 255)
  114.             IF alpha~& = 0 THEN EXIT DO '                                           if it is transparent then leave the loop
  115.             x% = x% + 1 '                                                           move right one pixel
  116.             IF x% > SL_sheet(handle%).sheetwidth THEN '                             have we gone off the sheet?
  117.                 x% = 0 '                                                            yes, reset back to the left beginning
  118.                 y% = y% + 1 '                                                       move down one pixel
  119.             END IF
  120.         LOOP UNTIL y% > SL_sheet(handle%).sheetheight '                             don't stop until the entire sheet has been checked
  121.         _SOURCE osource& '                                                          return source to current
  122.         IF alpha~& = 0 THEN '                                                       did we find a transparent pixel?
  123.             SL_sheet(handle%).transcolor = pixel~& '                                yes, set the sheet's transparency to this color
  124.         ELSE '                                                                      no transparency found within sheet
  125.             SL_sheet(handle%).transparency = 1 '                                    set to sheet having no alpha channel
  126.         END IF
  127.     ELSEIF transparency% = 0 THEN '                  (constant SL_SETTRANSPARENCY)  manually set alpha channel?
  128.         SL_sheet(handle%).transcolor = transcolor~& '                               yes, set alpha channel
  129.         _CLEARCOLOR transcolor~&, SL_sheet(handle%).sheetimage '                    apply alpha channel to sheet
  130.     END IF
  131.     SL_LOADSPRITESHEET = handle% '                                                  return the handle number pointing to this sheet
  132.  
  133.  
  134. '######################################################################################################################################
  135.  
  136. SUB SL_SPRITEERROR (routine$, errno%, info$) '                                                                           SL_SPRITEERROR
  137.     '+----------------------------------------------------------------------------+---------------------------------------------------+
  138.     '| Reports a Sprite Library error to the programmer. Used internally only.    |                     - NOTES -                     |
  139.     '|                                                                            | This routine will report the error to the         |
  140.     '| Input : routine$ - the function/subroutine the error occurred in           | programmer and halt the program                   |
  141.     '|                                                                            |                                                   |
  142.     '| Input : errno%   - the error number associated with the error              |                                                   |
  143.     '|                    100 - sprite does not exist                             |                                                   |
  144.     '|                    101 - sprite is not in use                              |                                                   |
  145.     '|                    102 - sprite can't be hidden                            |                                                   |
  146.     '|                    103 - invalid zoom value                                |                                                   |
  147.     '|                    104 - invalid rotation angle                            |                                                   |
  148.     '|                    105 - invalid flipping behavior                         |                                                   |
  149.     '|                    106 - sheet does not exist                              |                                                   |
  150.     '|                    107 - sheet is not in use                               |                                                   |
  151.     '|                    108 - invalid transparency setting                      |                                                   |
  152.     '|                    109 - invalid sprite width/height                       |                                                   |
  153.     '|                                                                            |                                                   |
  154.     '|         info$    - any information that need to be conveyed with the error |                                                   |
  155.     '|                    such as a file name                                     |                                                   |
  156.     '|                                                                            |                                                   |
  157.     '+----------------------------------------------------------------------------+---------------------------------------------------+
  158.     '| Known Issues: None                                                                                                             |
  159.     '|                                                                                                                                |
  160.     '+--------------------------------------------------------------------------------------------------------------------------------+
  161.     '| Credits: This routine was created in response to a request from QB64 member pitt                                               |
  162.     '|          http://www.[abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]/forum/index.php?topic=7281.0 (link no longer works)                                               |
  163.     '+--------------------------------------------------------------------------------------------------------------------------------+
  164.  
  165.     SCREEN 0, 0, 0, 0 '                                                             go to a pure text screen
  166.     _FONT 16 '                                                                      set the standard screen 0 font
  167.     IF _FULLSCREEN THEN _FULLSCREEN _OFF '                                          turn off full screen if on
  168.     _AUTODISPLAY '                                                                  auto update the display
  169.     CLS '                                                                           clear the screen
  170.     PRINT "**" '                                                                    print error header
  171.     PRINT "** Sprite Library error encountered"
  172.     PRINT "**"
  173.     PRINT
  174.     PRINT routine$; " has reported the following error:" '                          print sub/function reporting the error
  175.     PRINT
  176.     SELECT CASE errno% '                                                            which error number is being reported?
  177.         CASE 100
  178.             PRINT "- the specified sprite does not exist"
  179.             PRINT "- it was either never created or removed with SPRITEFREE"
  180.         CASE 101
  181.             PRINT "- the specified sprite is not in use"
  182.             PRINT "- it was probably removed with SPRITEFREE"
  183.         CASE 102
  184.             PRINT "- the specified sprite can't be hidden"
  185.             PRINT "- change the sprite's behavior in SPRITENEW to save background"
  186.         CASE 103
  187.             PRINT "- the zoom value specified must be greater than zero"
  188.         CASE 104
  189.             PRINT "- the angle specified must be 0 to 360"
  190.         CASE 105
  191.             PRINT "- invalid flipping behavior specified - valid settings are"
  192.             PRINT "- : 0 = no flipping     (constant SL_NONE)"
  193.             PRINT "- : 1 = flip horizontal (constant SL_HORIZONTAL)"
  194.             PRINT "- : 2 = flip vertical   (constant SL_VERTICAL)"
  195.             PRINT "- : 3 = flip both       (constant SL_BOTH)"
  196.         CASE 106
  197.             PRINT "- "; CHR$(34); info$; CHR$(34); " sprite sheet does not exist"
  198.             PRINT "- check path or spelling"
  199.         CASE 107
  200.             PRINT "- the specified sprite sheet is not in use"
  201.         CASE 108
  202.             PRINT "- invalid transparency setting supplied - valid settings are"
  203.             PRINT "- : -1 (constant SL_SHEETTRANSPARENCY)"
  204.             PRINT "- :  0 (constant SL_SETTRANSPARENCY)"
  205.             PRINT "- :  1 (constant SL_NOTRANSPARENCY)"
  206.         CASE 109
  207.             PRINT "- sprite width and height must be greater than zero"
  208.     END SELECT
  209.     DO: LOOP UNTIL INKEY$ = "" '                                                    clear the keyboard buffer
  210.     END '                                                                           end the program
  211.  
  212.  
  213.  
  214. '##################################################################################################################################
  215.  
  216.  
  217.  
« Last Edit: September 08, 2018, 03:24:10 am by TerryRitchie »
In order to understand recursion, one must first understand recursion.

Offline RhoSigma

  • QB64 Developer
  • Forum Resident
  • Posts: 565
    • View Profile
Re: Library section
« Reply #10 on: September 09, 2018, 09:32:36 am »
Quote
1) Subs/Functions should start with creator initial.  A Steve(tm) library would use SM_ for naming convention.  Sure, there might be more than one guy with the SM initials out there, but if there is, he hasn't posted much here on the forums, and all conflicts with SM_Xpos and TR_Xpos are instantly cleared up...
Although I mentioned this kind of ID earlier too here in this topic, after rethinking I came to the conclusion that we don't necessarily need IDs for SUB/FUNC names. Why?? - Every library has a specific purpose, eg. imageprocessing, spritesheets, menu, database, sorting etc., from that point of view the SUB/FUNC names should be unique enough between the different library types, as the names are usually chosen having the context of the respective library in mind. Even if there may exist more than one library for the same purpose, eg. three different spritesheet libs from three different authors, then still the user will most probably decide to use just one of it, the one which fits best for his needs.

Quote
2) GLOBAL Names should be self descriptive as much as possible.  SM_TextToImage is much easier to understand, remember, and use than SM_TTI, and chances are, it's also more resistant against accidental duplication.
Agreed, however for me it doesn't matter if the initials are representing the authors name or the library name/type. Every author should just be consistent on his preferred naming scheme.

Quote
3) COMMON variable names (such as any single digit character) should *always* be LOCAL and TEMPORARY in scope.  Don't DIM SHARED X, Y, I, K, M, ect...  Keep them reserved as temp variables and they should never interfere with another user's variables.
Totally agreed.

Quote
4) Unless NECESSARY, Subs/Functions should never pass values back via the parameter.  Instead of SUB SM_MathJunk (X, Y), values should be passed as SUB SM_MathJunk (TempX, TempY), with the next line reading X = TempX: Y = TempY.  This practice prevents all instances of accidental value corruption.
Agreed, however it seems you chose the easy way for you as library implementor. I personally would leave it as SUB SM_MathJunk (X, Y) for the public user and rather do tmpX = X: tmpY = Y internally, as any unexperienced user could be confused, if he reads to give "temporary" arguments to a SUB/FUNC call.
  Very important, if argument side effects are necessary/intended, then this MUST be explicitly mentioned in the respective function description. Also remind the potential user of such a SUB/FUNC that he should not use extra parenthesis to make a BYVAL parameter transfer. Also he can not give any literal values, but only variables of the very same variable type as specified in the parameter list, because QB64 would internally create a temporary parameter for literals or wrong variable types, which would compromise the intended side effect.
 
Quote
5) Arrays should be hard indexed.  Don't DIM SHARED Array(10); instead DIM SHARED Array(0 To 10).  This prevents incompatibility if the user has OPTION BASE 1 in effect.
Indeed, I've never thought about this one Steve, agreed.

Quote
6) Subs/Functions should *always* restore settings before exit.  If your sub needs a _DISPLAY to show text on the screen (such as for a message box), check to see if the user had _AUTODISPLAY on, and if so, restore it on exit.  _DEST, _SOURCE, _BLEND, COLOR, Visible Screen, and lots more *can* be altered while in a sub, but unless that's the intended purpose of the sub, it shouldn't happen in Library code.
Totally agreed.

Quote
7) Useage of Global Flags/Metacommands should be avoided.  DON'T count on DEFLNG A-Z to be set, or OPTION BASE to be 0/1, or $DYNAMIC to be in use.  Once you share a library publicly, you'll run into somebody who has the option set completely backwards of what you always ASSUMED was standard.
Indeed, never count on it and never ever even think on defining it in your library. Also, just as Terry mentioned, don't ever think on defining CONSTs for true/false, consider it would be the same as doing a DEFLNG A-Z in your library. Instead use type suffixes in your library code and literal booleans 0/-1 as suggested by Terry.

Ready for further revision of the rules....
My Projects:   https://qb64forum.alephc.xyz/index.php?topic=809
GuiTools - A graphic UI framework (can do multiple UI forms/windows in one program)
Libraries - ImageProcess, StringBuffers (virt. files), MD5/SHA2-Hash, LZW etc.
Bonus - Blankers, QB64/Notepad++ setup pack

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: Library section
« Reply #11 on: September 09, 2018, 10:44:30 am »
Interesting discussion. (I've not made or used libraries in ages.)

I like coding convention of all cap's for constants and dim shared variables but that is for regular code specially when not using Option _Explicit. OK for libraries too?

Trouble down the road with TRUE and FALSE would be? Several libraries attempting to do same?

FellippeHeitor

  • Guest
Re: Library section
« Reply #12 on: September 09, 2018, 10:58:12 am »
One should always declare even the simplest variable (even simple i for iterations) as users may choose to have OPTION _EXPLICIT in their programs. I always try to follow that rule in my reusable code.

Offline RhoSigma

  • QB64 Developer
  • Forum Resident
  • Posts: 565
    • View Profile
Re: Library section
« Reply #13 on: September 09, 2018, 11:12:19 am »
Trouble down the road with TRUE and FALSE would be? Several libraries attempting to do same?
Exactly, imagine 3 included *.bi files each of it containing the line CONST FALSE = 0, TRUE = NOT FALSE, then you certainly get the "Name already in use" status message.

Quote
One should always declare even the simplest variable (even simple i for iterations) as users may choose to have OPTION _EXPLICIT in their programs. I always try to follow that rule in my reusable code.
Does OPTION _EXPLICIT also affect temporary runtime variables local to a SUB/FUNC or is it valid for global variables only? I'll test this, if so we need to add this into rule #7.
My Projects:   https://qb64forum.alephc.xyz/index.php?topic=809
GuiTools - A graphic UI framework (can do multiple UI forms/windows in one program)
Libraries - ImageProcess, StringBuffers (virt. files), MD5/SHA2-Hash, LZW etc.
Bonus - Blankers, QB64/Notepad++ setup pack

FellippeHeitor

  • Guest
Re: Library section
« Reply #14 on: September 09, 2018, 11:34:02 am »
Option _Explicit makes it obligatory to declare any variables used in a program, no matter the scope. You can have variable i in several subs, but it must be declared in each.
« Last Edit: September 09, 2018, 11:44:04 am by FellippeHeitor »