I recently posted this question:
Doxygen configuration on Linux to ignore case sensitivity when put onto windows
The above posted was basically asking if there was a way to make Doxygen case sensitive so that when I use it, similar file titles such as CONE and cone get identified as different files and are saved as such.
Doxygen gave me a great answer by saying I should set CASE_SENSE_NAMES to "NO." It worked but unfortunately I realized it changed every capital letter in every title. Unfortunately i have over 3000 cases where this occurs and I can't go through and change the items linking to them.
So my main question is, is there a way to make doxygen case sensitive (similar to above) for only specific files. If i only wanted to it make the change to CONE and cone, how could I incorporate that in?
I love doxygen and have been using it for a long time! Thanks!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have forked a BSD-licensed project and made significant rewrites. In terms of numbers of characters, around 70% of the code was now written by me. I want to respect the original author's copyright while also receiving attribution for my work. Originally I intended to ask the best way to do that, but I see that according to this question I can just duplicate the original author's copyright line in the license file and put in my name and the year(s) of my work. Cool.
Now my question has to do with this line:
Neither the name of the PROJECTNAME nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
My rewrites have involved a significant change to the scope and direction of the application. I felt it appropriate to change the name of the app to better represent what my fork is. So:
Is changing the name cool? I don't see anything in the license that would prohibit it.
How best to represent this in the license? Should I replace the old project name with the new one? Should I modify that line to say "neither the name of the OLDPROJECTNAME, the name of the NEWPROJECTNAME, nor the names of its contributors..."?
I understand that no one here is going to give legal advice! I'm just looking for some general guidelines and best practices from the open source community.
You can change the name of the project, of course, BSD license being one of the most permissive ever, after public domain maybe.
It's not cool to keep the old name since you rewrote most of the code. And not fair for the original dev team.
If you are familiar with GPL-based licenses, they mostly have some clauses to make mentioning original authors and keeping the license mandatory. With BSD style, those aren't a problem anymore.
My answers are:
Consider yourself being an author of a fork, derived from any initial software but now doing things differently.
I guess you can attach any license you want now, since YOU are the author. Not sure about that though.
I want to respect the original author's copyright while also receiving attribution for my work.
It's nice you want to, but actually it's even a must. If you don't respect the usage terms given under BSD you would not have the right to rewrite the code (which you already did).
There are multiple ways how you can make the licensing of a software visible, whichever you have with your software make clear:
What is the name of the work (to make it identifiable) and who is the author of it, when was it written.
As your software makes use of other software, make clear under which license that other software is, which software it is, by whom it has been written etc..
If you want to allow your own changes and extendings to be re-used upstream in the project you forked, you should choose the same license for your work.
I felt it appropriate to change the name of the app to better represent what my fork is.
Is changing the name cool? I don't see anything in the license that would prohibit it.
The original usage conditions don't forbid you to change the project name. As you actually forked it, it makes very much sense that you change the name. Even if it's PROJECTNAME-user1311904-fork only or a completely different name.
How best to represent this in the license? Should I replace the old project name with the new one? Should I modify that line to say "neither the name of the OLDPROJECTNAME, the name of the NEWPROJECTNAME, nor the names of its contributors..."?
Actually as outlined above you have two licenses. You have got your license (the main license) which is for "your" software. And then you write that part of your software is licensed as. Then the original terms of the software your forked from are listed (as you got them from the original author). So it's clear what the licensing of your software is.
If you want to document this really good, you should put everything under version control, so it's technically possible to obtain the information what the original code was and what your changes are. So it's absolutely safely documented with the version control system to which part which license/es apply/ies.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What do you do with GitHub repositories you no longer maintain?
For whatever reason a project is started with a GitHub repository and then sometime later it's abandoned Perhaps it was an experiment that didn't work out. Perhaps you replaced it with a commercial product. Or perhaps you found a similar project to what you were doing and joined their efforts instead.
In the time your repository was alive, it attracted watchers and a few forks.
What do you do with it at that point? Is there a way to nicely indicate that repository is no longer maintained and to either check out the forks or a different project?
I'd do a single commit that removes all the source except for a README file that clearly states that you no longer have interst in the project (also copy the important parts of the README to the last commit log message, use git commit --amend if needed).
The README should explain that all the source code is still available as history. In addition the state of latest code should be described for maturity level: if it was used in production somewhere, it should be said here. If it was only an experiment and you never got it to compile correctly, then that should be said in capital letters. In the latter case, it might make some sense to just remove the code repository, though.
Obviously, the README should also contain the generic description of what your code does, but that should be already in the README.
Also try to put some words in the README that you expect potential users of that code to look for. Try to put those words close to the part that says that you're no longer maintaining the code.
The reasoning for this:
anybody interested in your source will still be able to get it (through history)
anybody trying to blindly merge your HEAD with his will immediately see that it's a bad idea (all source code will be removed and replaced with a README that explains why this happened)
I don't agree with the suggestion that if nobody has forked (and preserved the code), it's worth nothing. Perhaps the only reason somebody else has not taken over is that your project haven't been seen by enough many eyeballs.
If you believe that your code has any value (and I do mean anything above zero), then do not delete it. Just make it clear that the code has been abandoned.
Actually, I think pretty much the nicest thing you can do is to simply delete the repository. That way, the obsolete code doesn't show up in searches, for example.
The whole point of distributed version control is that no single repository is more important than another. If there is enough interest in the project, then one of the people who forked the repository will emerge as the new community leader. And if nobody forked it, then it probably wasn't worth preserving anyway.
I'd make a nice commit in the README file which basically states that this is here for historical reference, look at X Y and Z in order to see where this code went.
I prefix my projects with "deprecated." There are some posts on github's site regarding this, but it seems they won't budge. They want you to put a note in the readme. I'd prefer to put information in a relational database so you can sort on different fields, one of those being if the project is active or not.
I put my deprecated projects up there because there are concepts you can re-use. It is similar to your school work. Hopefully you can learn a lesson or 2 from it.
Walter
I've got lots of source code files written in various languages, but none of them have a standard comment at the top (sometimes even across the same project). Some of them don't have any header comment at all :-)
I've been thinking about creating a standard template that I can use at the top of my source files, and was wondering what fields I should include.
I know I want to include my name and a short description of what the file contains/does. Should I also include the date created? The date last modified? The programmer who last modified the file? What other fields have you found to be useful?
Any tips and comments welcome.
Thanks,
Cameron
This seems to be a dying practice.
Some people here on StackOverflow are against code comments altogether (reasoning that code should be written to be self explanatory) While I wouldn't go that far, some of the points of the anti-comment crowd make sense, such as the fact that comments tend to be out of date.
Header blocks of comments suffer from these symptoms even more so. Every organization I've been with that has had these header blocks, they are out of date. They have a author name of some guy who doesnt even work there any more, a description that does not match the code at all (assuming it ever did) and a last modified date, that once compared with version control history, seems to have missed its last dozen updates.
In my personal opinion, keep comments close to the code. If you want to know purpose of, and/or history of, a code file, use your version control system.
Date created, date modified and author who last changed the file should be stored in your source control software.
I usually put:
The main purpose of the file and things within the file.
The project/module the file belongs to.
The license associated with the file (and a LICENSE file in the project root).
Who is responsible for the file (either the team, person, or both)
Back in 2002, when I was straight out of college and jobs were few and far between after the dot-com bust, I joined a service company which used to create software customized for their clients in Java. I had to sit in the office of a client (which was a ramshackle room in an electric sub-station rigged with an AC to keep the servers running), sharing chairs/PCs with other guys in the team. The other engineers (if I can call them engineers ;) in the group used to make changes ad-hoc to the source code, compile the files and put them into production.
No way to figure out who made what change.
No way to figure out why any change was made.
No way to go to previous version of code, unless the engineer "remembered" what he modified.
Backup: Copy over files from the production server, which were replaced with new files.
Location of backup: Home directory of engineer copying over files to production server.
Reports of production servers going down due to botched attempts of copying over files to the server (missed a file to be copied over, backups getting lost or wrong files being copied over or not all files being copied over) were met with shrugs (oh no, is it down? let's see what happened; hey who changed what recently...? ummm...).
During those days, after spending several frustrating days trying to figure out the whos and whys behind the code, I had devised a system for comments in a list in the header of the source file which detailed the following:
Date of change made
Who made the change
Why was the change made
Two months later when the list threatened to challenge the size of the source code in the file, the manager had the bright idea of getting a source version control system.
I have never needed to put any comments in headers of source files (except for copyright notices) in any company I worked since. In my current company, everything else is mostly self-evident by looking at the code, or going to the bug reporting system which is integrated with the source version control system.
What fields do you need? If you have to ask whether to put some info there, you don't really need that info. Unless you are forced, by some bureaucratic incompetence of your employer, I don't see why you should go looking for more info than you already feel should be there.\
In most organizations, all source files have to begin with a legal blurb. If you're really lucky, it's just a one-liner, but in most cases it's a really long block of legalese. As a result, few people ever read these. Our eye just travels to the first program element and then goes up to its documentation.
So if you want to write anything, write it in association with the topmost program element, not the file.
Any other bookkeeping information should generally be part of your version control, not maintained (poorly) in the file itself.
In addition to the comment above stating license, the project that it belongs to, etc I also tend to put the "weird" requirements at the top as well (such as "built with version X of library Y") so you, or the person who picks it up after you won't change something that the program relies on without realizing it (or, if they do, they will at least know what to change back)
A lot depends on whether you're using an auto-documentation generation tool or not.
While I agree with many of the comments, if you're using JavaDoc or some other documentation generating tool that depends on comments, you'll obviously need to include the things it wants to see.
You did not mention that you are using a version control system and your comment in Neil N's answer confirms this for your older code. While using version control is the best way to go I also have experienced many situations where the cost of doing so for older code would not be paid for by the project's sponsor. If you do not have a centralized change history for the project then the change history can be put in the modules. It is good that you are using a version control system for your new code.
Your company name
All rights reserved (c) year - or reference to appropriate license
Project or library this file is for
Module it belongs to
Description of what it contains
History
-------
01/08/2010 - Programmer - version
Initial creation.
01/09/2010 - Programmer - version
Change description.
01/10/2010 - Programmer - version
Change description.
Those useful fields that you mentioned are good ones. Who modified the file and when.
Your version control software should allow for the embedding of keywords within comments. For example, in CVS, the $Id$ will resolve to the file, date/time modified, and user that modified the file. It will automatically be kept up to date with each check-in.
Include the following information:
What this file is for. That's a very useful piece of knowledge and it's more important than anything else. You should tell the reader, why there is such a file, why did you group functions in a separate file/package/module and why they are used. Maybe briefly, one or two lines, but that should be there.
Legal stuff, if appplicant.
Leave the place for special commands of console editors, such as of Emacs.
Add special commands that your auto-documenting system requires.
Things things you shouldn not include are
Who created the file
When it was created
Who modified it the last time
When it was last modified
What was added by the latest modification
You can--and should--retrieve it via the version control system, where it's constantly and automatically kept up-to-date. Let alone that most of these points are just useless.
Who created the file
When it was created
Who modified it the last time
When it was last modified
What was added by the latest modification
I need to decide on naming conventions for a new website.
I can use mod_rewrite at will.
My favourite solution would be to work with no file extension at all.
www.exampledomain.com/language/pagename
this would lead to "pagename" being treated as a directory. I would have to take that into account when using relative links.
Are there any other pitfalls I need to be aware of when doing this?
Is this legal, or are resources supposed to have a "name.prefix" structure?
Do you know of any clients that can't deal with this and start looking for /index.htm or .html?
Can you think of any SEO problems to be expected?
Unless you have a very good reason to add an extension, drop it.
are resources supposed to have a "name.prefix" structure?
Not that I know of. Normally not. Resources are just a concept. A custom resource format may have that extension requirement, the other would not. It will depend.
As for SEO, the short a link is, the better. It will increase relative weight of keywords. An extension would make links longer by 4 characters or more.
Do you know of any clients that can't deal with this and start looking for /index.htm or .html?
A problem may arise if you decide to support multiple entry points.
www.exampledomain.com
www.exampledomain.com/index.html
www.exampledomain.com//index.htm
www.exampledomain.com/index
These are all different urls to search engines. Some people will be linking to you with the shortest name, the others will use the other version. Then ultimately there will be different inbound links pointing to your site start page which will essentially be the same. Search engines will detect it and see it as content duplication. Consequently, your page rank will be divided between several url versions. Finally, all except one will likely be dropped out of their index entirely. To deal with this situation, decide for one "true" url and let others perform 301 redirect (moved permanently) to the "correct" url.
Dropping extensions actually has the significant benefit of not tying you to a specific language. If your URLs are http://example.com/page.php and you switch to another language, you'll either lose the existing URLs (bad!) or have to fake the PHP extension (clunky).