How many different/unique MATLAB/Simulink projects have you worked on?
18 Comments
Time Descending
Hey folks, can I get a job out of it. I am an electrical engineering graduate wanted to pursue Computer Science application, use MATLAB sometimes. I want to earn by using all this knowledge. Please suggest at ratangkp14@gmail.com
taucv calculation equation?
What counts as a project? A fileexchange entry that is more than 100 or so lines of code? Or a master's degree? That changes the order of magnitude for my answer
Like an m-file/app that does one unique job, like find the contact angle of droplets in an image. Not like small utility/helper functions. A masters degree may have several main programs to do a variety of things. One File Exchange submission would be one project. Personally I have about 300 major projects/apps (thousands of lines each) that I've done for work, plus another 400 demos that I've written for Answers that I may post someday.
I don't know. There are hobby things in MIMT that I've put orders of magnitude more actual time into than the work I did in postgrad research projects. Then again, the work I did back then was done in very condensed timeframes with less understanding of what I was doing and a lot more panic. I could see how the scale of what's implied by the word "project" could be quite subjective.
Don't over think it. No one is going to audit the accuracy of your response.
I suspect it will take a while before I get to that level.
I think it is a good sign that I pride myself on trying to make my FEX submissions so robust that even a utility function (like checking for an internet connection or reading a text file) can grow up to be a project.
I haven't looked at any of your submissions but hopefully you follow the mandatory requirements I tell all the people I teach how to program.
- Use descriptive variable names. No one can maintain or understand an alphabet soup of one or two letter variable names.
- Put in tons of comments. I average 37% of my lines of code are either a comment or have a comment on them, as checked by my attached comment counter app.
Did either of you modify it to handle block comments, like where you do %{ at the start and %} and the end and no % in between? I don't think I did that, so that would be one good addition.
I decided to come back to this.
- I used Rik's code to do the file processing, so that should be a big improvement. Block comments should now work, and the detection should be a lot more reliable than last time.
- I fixed the dependency on R2016b+ dir() behavior. Tested back to R2009b.
- It now also gets synopsis size info for function files.
- I also fixed a couple sorting bugs in the last incarnation.
I bet there are still things I missed and more edge cases to find, but it currently seems to handle all the files I throw at it. It's definitely slower than before, but it's also doing a lot more.
Just figured I'd share.
Would either of you object if I ever decided to put this on the FEX (with attribution)? I've given thought to posting my pile of MIMT maintenance tools, and if I did, this would be in the pile.
I was planning on posting my comment stripper separately, so then you can include it as a separate m-file (or as a link to the FEX/github). If you beat me to it, feel free to include it.
Well I doubt I'm going to beat anyone to anything, so we'll see. At the moment, checkcomments.m is the most non-MIMT-specific thing in my maintenance toolbox. The other stuff I've thought about still needs a lot of work to make it more generally useful for others. I just figured I'd ask now instead of in 2025 or something.
I didn't bother, since I never use block comments. I know that Rik's solution is robust, but I also know that it's more complex and that I would have had to modify either one to do the things I wanted. I just took the easy way for now and accepted the risk of error.
I think it would also be useful to collect information about the presence/size of synopses. I just haven't poked at that yet.
My replacement suggestion deals with block comments (and with edge cases of transpose operations on the same line as a format spec etc). Feel free to have a look.
(although I don't actually use block comments myself)
Maybe getting a bit O/T, but I tailored that function for my own use. It's generally more configurable, with multiple sorting options and the option to return the info as an array. The console output is a neatly formatted table.
Regarding my prior comment about how my own commenting style skews the percentages, the modified function can count either lines or characters. Counting lines gives a good image of comment distribution, favoring brief trailing comments. Counting characters describes commentary volume, favoring full-line comments.
I'm sure there are mistakes yet, but I think that's enough for the moment. I haven't fixed the R2016b+ dependency yet.
3. Have a full help synopsis that describes the function usage, its inputs and outputs.
Internal comments are valuable, if not to others, then for one's own documentation. I don't think that reading the code should be required to figure out how use a function. Considering the FEX and all the assignments that show up on the forum, I don't think anybody teaches that (or maybe everyone just uses webdocs instead of help?)
EDIT: This is pretty useful!
- Found 181 files in the 3 folders.
- Overall, in 41875 lines, 9049 lines (21.61 %) had comments.
- Most commented percentage for one file was 65%
- Most commented lines for one file was 991
I tend to prefer prefacing blocks of code with explanatory comments over distributing comments across many lines, so that probably skews things. I also format comments wider than MATLAB wants me to.
I just had a look myself:
For BibleDownloader, 21% of lines contain comments For BlandAltmanPlot, 38% of lines contain comments For ComputeNonCryptHash, 34% of lines contain comments For ETA_disp, 55% of lines contain comments For findND, 44% of lines contain comments For getUTC, 28% of lines contain comments For GetWritableFolder, 34% of lines contain comments For ifversion, 47% of lines contain comments For isnetavl, 36% of lines contain comments For JSON, 29% of lines contain comments For maximize, 42% of lines contain comments For minify, 39% of lines contain comments For PhotoAnnotation, 33% of lines contain comments For point_to_line_distance, 62% of lines contain comments For readdicomfolder, 31% of lines contain comments For readfile, 36% of lines contain comments For regexp_outkeys, 43% of lines contain comments For RegGrow, 37% of lines contain comments For save2mat, 27% of lines contain comments For sqlite3, 34% of lines contain comments For text2im, 32% of lines contain comments For WBM, 33% of lines contain comments For WindowLevel, 44% of lines contain comments
As with your code, this includes the documentation at the start of the function and averages out to 37.4%. I used a slightly different strategy to count the comments (using the comment stripper I wrote for minify). The resulting drop-in replacement for ProcessOneFile is attached.
