Are there guidelines for finding good names for LaTeX 2e packages and control sequences defined in these packages?Test if token is a control sequenceAre there any coding style guidelines for LaTeX?choosing macro names so as to avoid namespace conflictsTest if a given control sequence is an outer macroNaming conventions for macro names that include the package nameMacro names with one single figure like 2, a bad practice?TeX and Hyper text linksPotential side-effects associated with a dash in a package/class name?“Good” command names for typesetting matrices and vectorsexpl3: lowercase a token list inside a tikz node

When conversion from Integer to Single may lose precision

Required to check-in in person at international layover airport

Translating 'Liber'

Does an ice chest packed full of frozen food need ice?

PL/SQL function to receive a number and return its binary format

How hard would it be to convert a glider into an powered electric aircraft?

Does there exist a word to express a male who behaves as a female?

My coworkers think I had a long honeymoon. Actually I was diagnosed with cancer. How do I talk about it?

Traffic law UK, pedestrians

What can plausibly explain many of my very long and low-tech bridges?

How can you travel on a trans-Siberian train when it is fully booked?

Is it possible to (7 day) schedule sleep time of a hard drive?

Does the growth of home value benefit from compound interest?

Do any instruments not produce overtones?

Bent spoke design wheels — feasible?

How bad would a partial hash leak be, realistically?

What LISP compilers and interpreters were available for 8-bit machines?

Is it possible for people to live in the eye of a permanent hypercane?

Do the English have an ancient (obsolete) verb for the action of the book opening?

Strat tremolo bar has tightening issues

Pushout commutative diagram

Remove sudoers using script

Etymology of 'calcit(r)are'?

How to make thick Asian sauces?



Are there guidelines for finding good names for LaTeX 2e packages and control sequences defined in these packages?


Test if token is a control sequenceAre there any coding style guidelines for LaTeX?choosing macro names so as to avoid namespace conflictsTest if a given control sequence is an outer macroNaming conventions for macro names that include the package nameMacro names with one single figure like 2, a bad practice?TeX and Hyper text linksPotential side-effects associated with a dash in a package/class name?“Good” command names for typesetting matrices and vectorsexpl3: lowercase a token list inside a tikz node













17















I have written some code which I would like to submit to CTAN as a package for LaTeX 2e. (readme, dtx, ins, pdf with manual and commented sources.)



I need a good name for the package.
Question: Are there guidelines out there for finding good instructive names for LaTeX 2e-packages?



Also the control sequence tokens defined in the package need good instructive names from which the reader can easily deduce the rôle which a control sequence token plays and which do not lead to name-clashes with the kernel/with other packages.
Question: Are there guidelines out there for finding good instructive names for control sequence tokens which one wishes to define within a package?



By now I intend to do as follows:



Macros to be used by the user within the preamble or within the document-environment shall have names which are all in lowercase letters. These names shall enable the user to deduce a) the name of the package where the control sequence in question is defined and b) what the control sequence in question does.



Macros that form some "user interface" for adjustments: Same as above but a mixture of lowercase and uppercase letters. From the macro-name one should also easily deduce which user-level-macros'/document-level macros' workflows are to be influenced by the user-interface-macro/adjustment-macro in question.



Internal macros that form the core of the functionality provided by the package: Same as above, perhaps only lowercase-letters and something from which you can see the "internalness" of the macro in question, and also deduce the author who wrote the macro.



The most crucial point is finding good phrases which are not too long and from which a user can easily deduce what the macro in question does/shall be used for.
Question: Are there guidelines for finding good instructional phrases that can be part of a macro name and from which a user can easily deduce what the macro in question does/shall be used for?



In the first place assume fully expandable macro-based "mechanisms" which in the stage of macro expansion lead to carrying out more or less tricky algorithms and where understanding the algorithm implemented might already be a problem which requires some delving into the matter.

Understanding the interaction of the components which form the implementation should be eased up by instructive macro names...

The point is: In such situations I often end up with macro names which do help me understand things when looking at the code half a year later but which do not help others at all at getting through the things.



Any scheme for macro names I can think of myself makes very long macro names. ;-)










share|improve this question



















  • 3





    A user can probably guess what setPaperSize could do, sPS would be a different thing. There is just common sense that will help you in your endeavour.

    – Johannes_B
    May 20 at 13:34











  • @Johannes_B Especially regarding package names for CTAN there might be some restrictions/requirements that I am not aware of...

    – user189337
    May 20 at 13:52






  • 3





    TeX packages are just like any piece of software in this respect. There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

    – Seamus
    May 20 at 13:56






  • 3





    You should take a look at the good practices of other packages. A great example is the egregdoesnotlikesansseriftitles option of KOMA script.

    – Skillmon
    May 20 at 14:07






  • 4





    what you suggest sounds reasonable but good practice suggests giving all internal commands a package-specific prefix mypackage@this, mypackage@that for example so avoiding clashes with other packages. See also the LaTeX3 naming scheme which formalises many aspects of the command and module names)

    – David Carlisle
    May 20 at 14:22















17















I have written some code which I would like to submit to CTAN as a package for LaTeX 2e. (readme, dtx, ins, pdf with manual and commented sources.)



I need a good name for the package.
Question: Are there guidelines out there for finding good instructive names for LaTeX 2e-packages?



Also the control sequence tokens defined in the package need good instructive names from which the reader can easily deduce the rôle which a control sequence token plays and which do not lead to name-clashes with the kernel/with other packages.
Question: Are there guidelines out there for finding good instructive names for control sequence tokens which one wishes to define within a package?



By now I intend to do as follows:



Macros to be used by the user within the preamble or within the document-environment shall have names which are all in lowercase letters. These names shall enable the user to deduce a) the name of the package where the control sequence in question is defined and b) what the control sequence in question does.



Macros that form some "user interface" for adjustments: Same as above but a mixture of lowercase and uppercase letters. From the macro-name one should also easily deduce which user-level-macros'/document-level macros' workflows are to be influenced by the user-interface-macro/adjustment-macro in question.



Internal macros that form the core of the functionality provided by the package: Same as above, perhaps only lowercase-letters and something from which you can see the "internalness" of the macro in question, and also deduce the author who wrote the macro.



The most crucial point is finding good phrases which are not too long and from which a user can easily deduce what the macro in question does/shall be used for.
Question: Are there guidelines for finding good instructional phrases that can be part of a macro name and from which a user can easily deduce what the macro in question does/shall be used for?



In the first place assume fully expandable macro-based "mechanisms" which in the stage of macro expansion lead to carrying out more or less tricky algorithms and where understanding the algorithm implemented might already be a problem which requires some delving into the matter.

Understanding the interaction of the components which form the implementation should be eased up by instructive macro names...

The point is: In such situations I often end up with macro names which do help me understand things when looking at the code half a year later but which do not help others at all at getting through the things.



Any scheme for macro names I can think of myself makes very long macro names. ;-)










share|improve this question



















  • 3





    A user can probably guess what setPaperSize could do, sPS would be a different thing. There is just common sense that will help you in your endeavour.

    – Johannes_B
    May 20 at 13:34











  • @Johannes_B Especially regarding package names for CTAN there might be some restrictions/requirements that I am not aware of...

    – user189337
    May 20 at 13:52






  • 3





    TeX packages are just like any piece of software in this respect. There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

    – Seamus
    May 20 at 13:56






  • 3





    You should take a look at the good practices of other packages. A great example is the egregdoesnotlikesansseriftitles option of KOMA script.

    – Skillmon
    May 20 at 14:07






  • 4





    what you suggest sounds reasonable but good practice suggests giving all internal commands a package-specific prefix mypackage@this, mypackage@that for example so avoiding clashes with other packages. See also the LaTeX3 naming scheme which formalises many aspects of the command and module names)

    – David Carlisle
    May 20 at 14:22













17












17








17








I have written some code which I would like to submit to CTAN as a package for LaTeX 2e. (readme, dtx, ins, pdf with manual and commented sources.)



I need a good name for the package.
Question: Are there guidelines out there for finding good instructive names for LaTeX 2e-packages?



Also the control sequence tokens defined in the package need good instructive names from which the reader can easily deduce the rôle which a control sequence token plays and which do not lead to name-clashes with the kernel/with other packages.
Question: Are there guidelines out there for finding good instructive names for control sequence tokens which one wishes to define within a package?



By now I intend to do as follows:



Macros to be used by the user within the preamble or within the document-environment shall have names which are all in lowercase letters. These names shall enable the user to deduce a) the name of the package where the control sequence in question is defined and b) what the control sequence in question does.



Macros that form some "user interface" for adjustments: Same as above but a mixture of lowercase and uppercase letters. From the macro-name one should also easily deduce which user-level-macros'/document-level macros' workflows are to be influenced by the user-interface-macro/adjustment-macro in question.



Internal macros that form the core of the functionality provided by the package: Same as above, perhaps only lowercase-letters and something from which you can see the "internalness" of the macro in question, and also deduce the author who wrote the macro.



The most crucial point is finding good phrases which are not too long and from which a user can easily deduce what the macro in question does/shall be used for.
Question: Are there guidelines for finding good instructional phrases that can be part of a macro name and from which a user can easily deduce what the macro in question does/shall be used for?



In the first place assume fully expandable macro-based "mechanisms" which in the stage of macro expansion lead to carrying out more or less tricky algorithms and where understanding the algorithm implemented might already be a problem which requires some delving into the matter.

Understanding the interaction of the components which form the implementation should be eased up by instructive macro names...

The point is: In such situations I often end up with macro names which do help me understand things when looking at the code half a year later but which do not help others at all at getting through the things.



Any scheme for macro names I can think of myself makes very long macro names. ;-)










share|improve this question
















I have written some code which I would like to submit to CTAN as a package for LaTeX 2e. (readme, dtx, ins, pdf with manual and commented sources.)



I need a good name for the package.
Question: Are there guidelines out there for finding good instructive names for LaTeX 2e-packages?



Also the control sequence tokens defined in the package need good instructive names from which the reader can easily deduce the rôle which a control sequence token plays and which do not lead to name-clashes with the kernel/with other packages.
Question: Are there guidelines out there for finding good instructive names for control sequence tokens which one wishes to define within a package?



By now I intend to do as follows:



Macros to be used by the user within the preamble or within the document-environment shall have names which are all in lowercase letters. These names shall enable the user to deduce a) the name of the package where the control sequence in question is defined and b) what the control sequence in question does.



Macros that form some "user interface" for adjustments: Same as above but a mixture of lowercase and uppercase letters. From the macro-name one should also easily deduce which user-level-macros'/document-level macros' workflows are to be influenced by the user-interface-macro/adjustment-macro in question.



Internal macros that form the core of the functionality provided by the package: Same as above, perhaps only lowercase-letters and something from which you can see the "internalness" of the macro in question, and also deduce the author who wrote the macro.



The most crucial point is finding good phrases which are not too long and from which a user can easily deduce what the macro in question does/shall be used for.
Question: Are there guidelines for finding good instructional phrases that can be part of a macro name and from which a user can easily deduce what the macro in question does/shall be used for?



In the first place assume fully expandable macro-based "mechanisms" which in the stage of macro expansion lead to carrying out more or less tricky algorithms and where understanding the algorithm implemented might already be a problem which requires some delving into the matter.

Understanding the interaction of the components which form the implementation should be eased up by instructive macro names...

The point is: In such situations I often end up with macro names which do help me understand things when looking at the code half a year later but which do not help others at all at getting through the things.



Any scheme for macro names I can think of myself makes very long macro names. ;-)







macros best-practices naming






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 20 at 13:50







user189337

















asked May 20 at 13:28









user189337user189337

863




863







  • 3





    A user can probably guess what setPaperSize could do, sPS would be a different thing. There is just common sense that will help you in your endeavour.

    – Johannes_B
    May 20 at 13:34











  • @Johannes_B Especially regarding package names for CTAN there might be some restrictions/requirements that I am not aware of...

    – user189337
    May 20 at 13:52






  • 3





    TeX packages are just like any piece of software in this respect. There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

    – Seamus
    May 20 at 13:56






  • 3





    You should take a look at the good practices of other packages. A great example is the egregdoesnotlikesansseriftitles option of KOMA script.

    – Skillmon
    May 20 at 14:07






  • 4





    what you suggest sounds reasonable but good practice suggests giving all internal commands a package-specific prefix mypackage@this, mypackage@that for example so avoiding clashes with other packages. See also the LaTeX3 naming scheme which formalises many aspects of the command and module names)

    – David Carlisle
    May 20 at 14:22












  • 3





    A user can probably guess what setPaperSize could do, sPS would be a different thing. There is just common sense that will help you in your endeavour.

    – Johannes_B
    May 20 at 13:34











  • @Johannes_B Especially regarding package names for CTAN there might be some restrictions/requirements that I am not aware of...

    – user189337
    May 20 at 13:52






  • 3





    TeX packages are just like any piece of software in this respect. There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

    – Seamus
    May 20 at 13:56






  • 3





    You should take a look at the good practices of other packages. A great example is the egregdoesnotlikesansseriftitles option of KOMA script.

    – Skillmon
    May 20 at 14:07






  • 4





    what you suggest sounds reasonable but good practice suggests giving all internal commands a package-specific prefix mypackage@this, mypackage@that for example so avoiding clashes with other packages. See also the LaTeX3 naming scheme which formalises many aspects of the command and module names)

    – David Carlisle
    May 20 at 14:22







3




3





A user can probably guess what setPaperSize could do, sPS would be a different thing. There is just common sense that will help you in your endeavour.

– Johannes_B
May 20 at 13:34





A user can probably guess what setPaperSize could do, sPS would be a different thing. There is just common sense that will help you in your endeavour.

– Johannes_B
May 20 at 13:34













@Johannes_B Especially regarding package names for CTAN there might be some restrictions/requirements that I am not aware of...

– user189337
May 20 at 13:52





@Johannes_B Especially regarding package names for CTAN there might be some restrictions/requirements that I am not aware of...

– user189337
May 20 at 13:52




3




3





TeX packages are just like any piece of software in this respect. There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

– Seamus
May 20 at 13:56





TeX packages are just like any piece of software in this respect. There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

– Seamus
May 20 at 13:56




3




3





You should take a look at the good practices of other packages. A great example is the egregdoesnotlikesansseriftitles option of KOMA script.

– Skillmon
May 20 at 14:07





You should take a look at the good practices of other packages. A great example is the egregdoesnotlikesansseriftitles option of KOMA script.

– Skillmon
May 20 at 14:07




4




4





what you suggest sounds reasonable but good practice suggests giving all internal commands a package-specific prefix mypackage@this, mypackage@that for example so avoiding clashes with other packages. See also the LaTeX3 naming scheme which formalises many aspects of the command and module names)

– David Carlisle
May 20 at 14:22





what you suggest sounds reasonable but good practice suggests giving all internal commands a package-specific prefix mypackage@this, mypackage@that for example so avoiding clashes with other packages. See also the LaTeX3 naming scheme which formalises many aspects of the command and module names)

– David Carlisle
May 20 at 14:22










2 Answers
2






active

oldest

votes


















12














Naming schemes for package internal macros and user macros should be different since they have different purposes.



Internal naming conventions



Internal macros should be named to maximally avoid package conflicts, and secondarily to avoid users from modifying them directly. Most packages and classes use some variant of the following scheme:



  • package internal prefix or suffix separated with @. The prefix itself might be based on the package name, or the author's initials or some other scheme that is unlikely to produce a conflict.

For example, I maintain a thesis document class for Michigan State University, and all of the internal macros use the prefix msu@. The naming conventions within the package can be as descriptive as you want. I prefer fairly descriptive names even if they are relatively long since it makes reading the code easier.



  • msu@degree

  • msu@fieldofstudy

Many authors (especially those who use docstrip) like to use a suffix instead of a prefix, since this makes the index of macros in the documentation more usable. In this case the macros above would be the following. (They would then be indexed under d and f that than all being in a big m list.)



  • degree@msu

  • fieldofstudy@msu

User macros



The criteria for naming user macros are somewhat different. Depending on the functionality your package provides, naming conflicts may be less of a problem, since two package that provide the same functionality would likely not be used together. But it's best to avoid very generic names which might be used in multiple packages.



The balance between length and descriptiveness is quite subjective. If a macro will be used a lot, a long name is probably inadvisable, but if it's used once in a preamble, length is less of an issue.



Some authors also use the prefix method for user macros too, however, as this dramatically decreases the risk of conflicts. A notable example of this naming scheme is datatool which uses the DTL prefix for all user macros. Here the prefix is upper case to separate it out from the rest of the macro name which is relatively descriptive.



  • DTLloaddb

  • DTLforeach





share|improve this answer
































    8














    The following resources might be of interest to you:



    CTAN - Comprehensive TEX Archive Network - How can I up­load a pack­age?



    CTAN - Comprehensive TEX Archive Network - Ad­di­tional In­for­ma­tion for CTAN Uploaders, especially the section "Con­di­tions on pack­age ids".



    Here you find guidelines and phrases like



    e. New pack­ages and bun­dles should not be named af­ter their au­thors,
    but af­ter the pur­pose they are serv­ing,
    be­cause they may later
    be taken over by other main­tain­ers. (We know that there are a few
    well es­tab­lished CTAN pack­ages that do not ful­fill this rule; but
    that comes un­der “pro­tec­tion of vested rights”, and we have now
    learned from his­tory.)





    share|improve this answer

























    • So I guess LaTeX itself is an exception to this rule? :-D

      – Matthew Leingang
      May 21 at 19:17






    • 1





      @MatthewLeingang It's LaGacy code.

      – Alan Munn
      May 21 at 22:18











    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "85"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f491760%2fare-there-guidelines-for-finding-good-names-for-latex-2e-packages-and-control-se%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    12














    Naming schemes for package internal macros and user macros should be different since they have different purposes.



    Internal naming conventions



    Internal macros should be named to maximally avoid package conflicts, and secondarily to avoid users from modifying them directly. Most packages and classes use some variant of the following scheme:



    • package internal prefix or suffix separated with @. The prefix itself might be based on the package name, or the author's initials or some other scheme that is unlikely to produce a conflict.

    For example, I maintain a thesis document class for Michigan State University, and all of the internal macros use the prefix msu@. The naming conventions within the package can be as descriptive as you want. I prefer fairly descriptive names even if they are relatively long since it makes reading the code easier.



    • msu@degree

    • msu@fieldofstudy

    Many authors (especially those who use docstrip) like to use a suffix instead of a prefix, since this makes the index of macros in the documentation more usable. In this case the macros above would be the following. (They would then be indexed under d and f that than all being in a big m list.)



    • degree@msu

    • fieldofstudy@msu

    User macros



    The criteria for naming user macros are somewhat different. Depending on the functionality your package provides, naming conflicts may be less of a problem, since two package that provide the same functionality would likely not be used together. But it's best to avoid very generic names which might be used in multiple packages.



    The balance between length and descriptiveness is quite subjective. If a macro will be used a lot, a long name is probably inadvisable, but if it's used once in a preamble, length is less of an issue.



    Some authors also use the prefix method for user macros too, however, as this dramatically decreases the risk of conflicts. A notable example of this naming scheme is datatool which uses the DTL prefix for all user macros. Here the prefix is upper case to separate it out from the rest of the macro name which is relatively descriptive.



    • DTLloaddb

    • DTLforeach





    share|improve this answer





























      12














      Naming schemes for package internal macros and user macros should be different since they have different purposes.



      Internal naming conventions



      Internal macros should be named to maximally avoid package conflicts, and secondarily to avoid users from modifying them directly. Most packages and classes use some variant of the following scheme:



      • package internal prefix or suffix separated with @. The prefix itself might be based on the package name, or the author's initials or some other scheme that is unlikely to produce a conflict.

      For example, I maintain a thesis document class for Michigan State University, and all of the internal macros use the prefix msu@. The naming conventions within the package can be as descriptive as you want. I prefer fairly descriptive names even if they are relatively long since it makes reading the code easier.



      • msu@degree

      • msu@fieldofstudy

      Many authors (especially those who use docstrip) like to use a suffix instead of a prefix, since this makes the index of macros in the documentation more usable. In this case the macros above would be the following. (They would then be indexed under d and f that than all being in a big m list.)



      • degree@msu

      • fieldofstudy@msu

      User macros



      The criteria for naming user macros are somewhat different. Depending on the functionality your package provides, naming conflicts may be less of a problem, since two package that provide the same functionality would likely not be used together. But it's best to avoid very generic names which might be used in multiple packages.



      The balance between length and descriptiveness is quite subjective. If a macro will be used a lot, a long name is probably inadvisable, but if it's used once in a preamble, length is less of an issue.



      Some authors also use the prefix method for user macros too, however, as this dramatically decreases the risk of conflicts. A notable example of this naming scheme is datatool which uses the DTL prefix for all user macros. Here the prefix is upper case to separate it out from the rest of the macro name which is relatively descriptive.



      • DTLloaddb

      • DTLforeach





      share|improve this answer



























        12












        12








        12







        Naming schemes for package internal macros and user macros should be different since they have different purposes.



        Internal naming conventions



        Internal macros should be named to maximally avoid package conflicts, and secondarily to avoid users from modifying them directly. Most packages and classes use some variant of the following scheme:



        • package internal prefix or suffix separated with @. The prefix itself might be based on the package name, or the author's initials or some other scheme that is unlikely to produce a conflict.

        For example, I maintain a thesis document class for Michigan State University, and all of the internal macros use the prefix msu@. The naming conventions within the package can be as descriptive as you want. I prefer fairly descriptive names even if they are relatively long since it makes reading the code easier.



        • msu@degree

        • msu@fieldofstudy

        Many authors (especially those who use docstrip) like to use a suffix instead of a prefix, since this makes the index of macros in the documentation more usable. In this case the macros above would be the following. (They would then be indexed under d and f that than all being in a big m list.)



        • degree@msu

        • fieldofstudy@msu

        User macros



        The criteria for naming user macros are somewhat different. Depending on the functionality your package provides, naming conflicts may be less of a problem, since two package that provide the same functionality would likely not be used together. But it's best to avoid very generic names which might be used in multiple packages.



        The balance between length and descriptiveness is quite subjective. If a macro will be used a lot, a long name is probably inadvisable, but if it's used once in a preamble, length is less of an issue.



        Some authors also use the prefix method for user macros too, however, as this dramatically decreases the risk of conflicts. A notable example of this naming scheme is datatool which uses the DTL prefix for all user macros. Here the prefix is upper case to separate it out from the rest of the macro name which is relatively descriptive.



        • DTLloaddb

        • DTLforeach





        share|improve this answer















        Naming schemes for package internal macros and user macros should be different since they have different purposes.



        Internal naming conventions



        Internal macros should be named to maximally avoid package conflicts, and secondarily to avoid users from modifying them directly. Most packages and classes use some variant of the following scheme:



        • package internal prefix or suffix separated with @. The prefix itself might be based on the package name, or the author's initials or some other scheme that is unlikely to produce a conflict.

        For example, I maintain a thesis document class for Michigan State University, and all of the internal macros use the prefix msu@. The naming conventions within the package can be as descriptive as you want. I prefer fairly descriptive names even if they are relatively long since it makes reading the code easier.



        • msu@degree

        • msu@fieldofstudy

        Many authors (especially those who use docstrip) like to use a suffix instead of a prefix, since this makes the index of macros in the documentation more usable. In this case the macros above would be the following. (They would then be indexed under d and f that than all being in a big m list.)



        • degree@msu

        • fieldofstudy@msu

        User macros



        The criteria for naming user macros are somewhat different. Depending on the functionality your package provides, naming conflicts may be less of a problem, since two package that provide the same functionality would likely not be used together. But it's best to avoid very generic names which might be used in multiple packages.



        The balance between length and descriptiveness is quite subjective. If a macro will be used a lot, a long name is probably inadvisable, but if it's used once in a preamble, length is less of an issue.



        Some authors also use the prefix method for user macros too, however, as this dramatically decreases the risk of conflicts. A notable example of this naming scheme is datatool which uses the DTL prefix for all user macros. Here the prefix is upper case to separate it out from the rest of the macro name which is relatively descriptive.



        • DTLloaddb

        • DTLforeach






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited May 20 at 18:28

























        answered May 20 at 14:27









        Alan MunnAlan Munn

        165k29434719




        165k29434719





















            8














            The following resources might be of interest to you:



            CTAN - Comprehensive TEX Archive Network - How can I up­load a pack­age?



            CTAN - Comprehensive TEX Archive Network - Ad­di­tional In­for­ma­tion for CTAN Uploaders, especially the section "Con­di­tions on pack­age ids".



            Here you find guidelines and phrases like



            e. New pack­ages and bun­dles should not be named af­ter their au­thors,
            but af­ter the pur­pose they are serv­ing,
            be­cause they may later
            be taken over by other main­tain­ers. (We know that there are a few
            well es­tab­lished CTAN pack­ages that do not ful­fill this rule; but
            that comes un­der “pro­tec­tion of vested rights”, and we have now
            learned from his­tory.)





            share|improve this answer

























            • So I guess LaTeX itself is an exception to this rule? :-D

              – Matthew Leingang
              May 21 at 19:17






            • 1





              @MatthewLeingang It's LaGacy code.

              – Alan Munn
              May 21 at 22:18















            8














            The following resources might be of interest to you:



            CTAN - Comprehensive TEX Archive Network - How can I up­load a pack­age?



            CTAN - Comprehensive TEX Archive Network - Ad­di­tional In­for­ma­tion for CTAN Uploaders, especially the section "Con­di­tions on pack­age ids".



            Here you find guidelines and phrases like



            e. New pack­ages and bun­dles should not be named af­ter their au­thors,
            but af­ter the pur­pose they are serv­ing,
            be­cause they may later
            be taken over by other main­tain­ers. (We know that there are a few
            well es­tab­lished CTAN pack­ages that do not ful­fill this rule; but
            that comes un­der “pro­tec­tion of vested rights”, and we have now
            learned from his­tory.)





            share|improve this answer

























            • So I guess LaTeX itself is an exception to this rule? :-D

              – Matthew Leingang
              May 21 at 19:17






            • 1





              @MatthewLeingang It's LaGacy code.

              – Alan Munn
              May 21 at 22:18













            8












            8








            8







            The following resources might be of interest to you:



            CTAN - Comprehensive TEX Archive Network - How can I up­load a pack­age?



            CTAN - Comprehensive TEX Archive Network - Ad­di­tional In­for­ma­tion for CTAN Uploaders, especially the section "Con­di­tions on pack­age ids".



            Here you find guidelines and phrases like



            e. New pack­ages and bun­dles should not be named af­ter their au­thors,
            but af­ter the pur­pose they are serv­ing,
            be­cause they may later
            be taken over by other main­tain­ers. (We know that there are a few
            well es­tab­lished CTAN pack­ages that do not ful­fill this rule; but
            that comes un­der “pro­tec­tion of vested rights”, and we have now
            learned from his­tory.)





            share|improve this answer















            The following resources might be of interest to you:



            CTAN - Comprehensive TEX Archive Network - How can I up­load a pack­age?



            CTAN - Comprehensive TEX Archive Network - Ad­di­tional In­for­ma­tion for CTAN Uploaders, especially the section "Con­di­tions on pack­age ids".



            Here you find guidelines and phrases like



            e. New pack­ages and bun­dles should not be named af­ter their au­thors,
            but af­ter the pur­pose they are serv­ing,
            be­cause they may later
            be taken over by other main­tain­ers. (We know that there are a few
            well es­tab­lished CTAN pack­ages that do not ful­fill this rule; but
            that comes un­der “pro­tec­tion of vested rights”, and we have now
            learned from his­tory.)






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited May 20 at 14:42

























            answered May 20 at 14:37









            Ulrich DiezUlrich Diez

            6,107621




            6,107621












            • So I guess LaTeX itself is an exception to this rule? :-D

              – Matthew Leingang
              May 21 at 19:17






            • 1





              @MatthewLeingang It's LaGacy code.

              – Alan Munn
              May 21 at 22:18

















            • So I guess LaTeX itself is an exception to this rule? :-D

              – Matthew Leingang
              May 21 at 19:17






            • 1





              @MatthewLeingang It's LaGacy code.

              – Alan Munn
              May 21 at 22:18
















            So I guess LaTeX itself is an exception to this rule? :-D

            – Matthew Leingang
            May 21 at 19:17





            So I guess LaTeX itself is an exception to this rule? :-D

            – Matthew Leingang
            May 21 at 19:17




            1




            1





            @MatthewLeingang It's LaGacy code.

            – Alan Munn
            May 21 at 22:18





            @MatthewLeingang It's LaGacy code.

            – Alan Munn
            May 21 at 22:18

















            draft saved

            draft discarded
















































            Thanks for contributing an answer to TeX - LaTeX Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f491760%2fare-there-guidelines-for-finding-good-names-for-latex-2e-packages-and-control-se%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Wikipedia:Vital articles Мазмуну Biography - Өмүр баян Philosophy and psychology - Философия жана психология Religion - Дин Social sciences - Коомдук илимдер Language and literature - Тил жана адабият Science - Илим Technology - Технология Arts and recreation - Искусство жана эс алуу History and geography - Тарых жана география Навигация менюсу

            Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

            What should I write in an apology letter, since I have decided not to join a company after accepting an offer letterShould I keep looking after accepting a job offer?What should I do when I've been verbally told I would get an offer letter, but still haven't gotten one after 4 weeks?Do I accept an offer from a company that I am not likely to join?New job hasn't confirmed starting date and I want to give current employer as much notice as possibleHow should I address my manager in my resignation letter?HR delayed background verification, now jobless as resignedNo email communication after accepting a formal written offer. How should I phrase the call?What should I do if after receiving a verbal offer letter I am informed that my written job offer is put on hold due to some internal issues?Should I inform the current employer that I am about to resign within 1-2 weeks since I have signed the offer letter and waiting for visa?What company will do, if I send their offer letter to another company