Modify

Opened 10 years ago

Closed 10 years ago

#1307 closed Feature Request (Rejected)

Better and consistent naming of boolean parameters in UDF functions

Reported by: Bowmore Owned by: Gary
Milestone: Component: Standard UDFs
Version: Severity: None
Keywords: Cc:

Description

I would like to request that a bit more consistent logic is used in the naming of boolean parameters in UDF function. Particularly optional ones. This request was prompted by when I needed to use _StringBetween in case sensitive mode. From the help file it was not obvious what value I should use for the $v_Case parameter. Looking at string.au3 I found that I could use anything except the keyword Default or -1.

I think it might be more intuitive to most people if such optional boolean parameters used True / False values in the help file and were named to express the positive vale of the default option.

Examples of suggested changes:

_StringBetween($s_String, $s_Start, $s_End [, $v_Case = -1])
To
_StringBetween($s_String, $s_Start, $s_End [, $fCaseInsensitive = True])
; the default for most string functions is case insensitive
ArraySort(ByRef $avArray[, $iDescending = 0 [, $iStart = 0 [, $iEnd = 0 [, $iSubItem = 0]]]])
To
_ArraySort(ByRef $avArray[, $fSortAssending = True [, $iStart = 0 [, $iEnd = 0 [, $iSubItem = 0]]]])
;the default for most sorting functions is ascending
_DateToMonth($iMonth [, $ishort = 0])
To
_DateToMonth($iMonth [, $fLongName = True])

_ArrayTrim(ByRef $avArray, $iTrimNum[, $iDirection = 0[, $iStart = 0[, $iEnd = 0]]])
To
_ArrayTrim(ByRef $avArray, $iTrimNum[, $fTrimRight = True[, $iStart = 0[, $iEnd = 0]]])

I think this can be done with only minor changes to the relevant functions and would not break any existing scripts. It would also make it easier to choose the correct value for the displayed call tips in SciTe.

Attachments (0)

Change History (1)

comment:1 Changed 10 years ago by Valik

  • Resolution set to Rejected
  • Status changed from new to closed

Code comes from more than one individual and we currently have no requirements on how it should be formatted. I'm closing this because it's an all or nothing thing. Either we review all code and ensure it conforms to a format we come up with, or we do nothing. At this point in time, we do nothing.

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Gary.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.