Skip to main content
added 64 characters in body
Source Link
user296862
user296862

I would first start by saying that if your developers are reluctant to contribute code because of your standards, either your standards are too rigorous or you should improve the quality and work ethic of your developers. If these are small scripts, there shouldn't be much extra effort required to put a couple comments in. Developers should be writing readable code by default, and if they aren't, your real problem lies in your staffing.

To answer your question, you have a few options:

  1. If the scripts are generic enough, you could host them in a separate repository. If the scripts are very project-centric, this may not work.
  2. Host the scripts in the same repository in a directory of their own. For example, at my company our projects usually have a cli/ directory which contains a handful of command line scripts, usually meant to be run one-off to initialize environments, import certain pieces of data, and so on.
  3. This is by far the worstcould be a poor option depending on what your needs are, but if you have some political issue in place preventingreason you from committingcan't commit code that doesn't expressly follow your standards, and/or you have developers who aren't willing to write scripts if they have to follow those standards, you could host the files on a shared drive or something similar. This is a pretty terriblemay not be the greatest solution sinceif you loseneed all the benefits of source control, but -- however it is a solution.can be beneficial in some circumstances (thanks Doc Brown for this edit)

With either of the first two options, you can choose to enact more lax coding standards on either the other repository or the directory.

I would first start by saying that if your developers are reluctant to contribute code because of your standards, either your standards are too rigorous or you should improve the quality and work ethic of your developers. If these are small scripts, there shouldn't be much extra effort required to put a couple comments in. Developers should be writing readable code by default, and if they aren't, your real problem lies in your staffing.

To answer your question, you have a few options:

  1. If the scripts are generic enough, you could host them in a separate repository. If the scripts are very project-centric, this may not work.
  2. Host the scripts in the same repository in a directory of their own. For example, at my company our projects usually have a cli/ directory which contains a handful of command line scripts, usually meant to be run one-off to initialize environments, import certain pieces of data, and so on.
  3. This is by far the worst option, but if you have some political issue in place preventing you from committing code that doesn't expressly follow your standards and you have developers who aren't willing to write scripts if they have to follow those standards, you could host the files on a shared drive or something similar. This is a pretty terrible solution since you lose all the benefits of source control, but it is a solution.

With either of the first two options, you can choose to enact more lax coding standards on either the other repository or the directory.

I would first start by saying that if your developers are reluctant to contribute code because of your standards, either your standards are too rigorous or you should improve the quality and work ethic of your developers. If these are small scripts, there shouldn't be much extra effort required to put a couple comments in. Developers should be writing readable code by default, and if they aren't, your real problem lies in your staffing.

To answer your question, you have a few options:

  1. If the scripts are generic enough, you could host them in a separate repository. If the scripts are very project-centric, this may not work.
  2. Host the scripts in the same repository in a directory of their own. For example, at my company our projects usually have a cli/ directory which contains a handful of command line scripts, usually meant to be run one-off to initialize environments, import certain pieces of data, and so on.
  3. This could be a poor option depending on what your needs are, but if you have some reason you can't commit code that doesn't expressly follow your standards, and/or you have developers who aren't willing to write scripts if they have to follow those standards, you could host the files on a shared drive or something similar. This may not be the greatest solution if you need all the benefits of source control -- however it can be beneficial in some circumstances (thanks Doc Brown for this edit)

With either of the first two options, you can choose to enact more lax coding standards on either the other repository or the directory.

Source Link
user296862
user296862

I would first start by saying that if your developers are reluctant to contribute code because of your standards, either your standards are too rigorous or you should improve the quality and work ethic of your developers. If these are small scripts, there shouldn't be much extra effort required to put a couple comments in. Developers should be writing readable code by default, and if they aren't, your real problem lies in your staffing.

To answer your question, you have a few options:

  1. If the scripts are generic enough, you could host them in a separate repository. If the scripts are very project-centric, this may not work.
  2. Host the scripts in the same repository in a directory of their own. For example, at my company our projects usually have a cli/ directory which contains a handful of command line scripts, usually meant to be run one-off to initialize environments, import certain pieces of data, and so on.
  3. This is by far the worst option, but if you have some political issue in place preventing you from committing code that doesn't expressly follow your standards and you have developers who aren't willing to write scripts if they have to follow those standards, you could host the files on a shared drive or something similar. This is a pretty terrible solution since you lose all the benefits of source control, but it is a solution.

With either of the first two options, you can choose to enact more lax coding standards on either the other repository or the directory.