投票
How many different/unique MATLAB/Simulink projects have you worked on?
18 个评论
时间降序
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.
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.
