User:KeshaSShah/GSoC13/Priority2

Project Title:

STEP LIBRARIES

Detailed project description

• Most of my fellow participants are working on how important it is to keep your code in working order and adding functionalities to it, but hardly anyone ever really cares about keeping the container for your code in working order.
• STEP is the current standard for exchange of CAD data between different software packages. BRL-CAD makes use of the NIST STEP Class Libraries code to support its step-g converter, but this source code was written before many current C++ standard practices and libraries were finalized. As a consequence, it needs both cleanup and performance enhancements.
• There is already an existing STEPcode repo at https://github.com/stepcode/stepcode which needs to be modernized and improved.
• Improvement is needed for LIBRARY PERFORMANCE, CODE MAINTAINABILITY, and better DOCUMENT the STEP libraries.
• BRL-CAD's step-g converter will serve as a test for the functionality of the library and compiler will be set to strict flags.
• Right now, I am learning about STEP libraries and studing the directory.

• I went through some issues related to cleanup and part21 and would like to contribute fixing them. I am particularly addressing and reviewing these issues and help them getting organized-
  • Issue 227: Merge major BRL-CAD SCL changes into stepcode
  • Issue 90: Statistics from p21read:
  • Issue 204: fedex_plus: add doxygen-style comments to the generated C++
  • Issue 197: error handling - option to summarize errors in p21read, fedex_plus
  • Issue 170: STEPfile::MakeBackupFile() is inefficient
  • Issue 21: cppcheck 1.49 issues report

• Still I am not completely done with this and would be updating this proposal as and how I understand and get directions.

Why Refactoring Is Needed ?

• Poorly designed code usually takes more code to do the same things, often because the code quite literally does the same thing in several places. By eliminating this duplicates, we ensure that the code says everything once and only once, which is the essence of good design.
• Mostly, when the developers are trying to get the program to work, they are not thinking about that future developer. It takes a change of rhythm to make changes that make the code easier to understand. Refactoring helps to make the code more readable. A little time spent refactoring can make the code better communicate its purpose.
• As the code gets clearer, one can see things about the design that he could not see before because its difficult to visualize all this in head. Thus, refactoring is just wiping the dirt off a window so you can see beyond.
• When I myself did some projects on making my own shell, implementing malloc and some data structure projects, I realized, while I’m studying code I find refactoring leads me to higher levels of understanding that otherwise I would miss out.
• Reducing and refactoring the amount of code does, however, make a big difference in modification of the code. The more code there is, the harder it is to modify correctly. Hence, this needs to be done as early as possible as everyday developers are working and adding new and new code to it.

• The above is what I intend to do as part of GSoC.
• It is not just about 3 months of GSoC, I want to be committed with this code for years. I will keep contributing even after that as thing is an endless job-new codes are definitely going to be added and that in-turn would also require code reducing and refactoring. Moreover, by the end of 3 months, I believe, I would have hacked the entire source code so well that I can work on other projects also and contribute in making BRD-CAL more awesome!

Links to any code or algorithms you intend to use

ALGORITHM I intend to use:

• Step1:Select one or more defect to review.
• Step2: Mark as claimed and being worked on.
• Step3: if ( More than three lines of code ) goto step 4 else Change according to my Judgment
• Step4: If ( More than in a file ) then goto step 5 else goto step 8
• Step5: If ( More than a directory ) then goto step 6 else goto step 7
• Step6: Probably warrants a new function in the highest common library and goto step 11
• Step7: Create function, add declaration to private header and goto step 11
• Step8: If ( In a library ) then goto step 9 else goto step 10
• Step9: Create hidden/static function or macro in the same file and goto step 11
• Step10: Create static function or macro in the same file and goto step 11
• Step11: If it warrants a regression test the goto step 12 else goto step 13.
• Step12: Add regression/ unit test and commit and goto step 14.
• Step13: If it is user visible goto step 14 else goto step 15.
• Step14: Update TODO and goto step 15

/* Here check once again for was it good code to change and leaves back no duplication, has a regression or unit test if warranted and it passes and all docs were updated like TODO, deprecation.txt, doc-book, doxygen comments etc */

• Step15: Commit and mark as 'Needs Review' and goto step 16
• Step 16: Estimate impact, update severity and goto step 17.
• Step 17: Record in the ledger and goto step 1.

Problems I would encounter and how will I solve them ?

• The task of code refactoring and reducing is very critical as it play around with most of the folders and files present in the source folder and will modify and delete and add some new lines as per the requirements. There is huge possibility of changing the functionality of the program and make it behave in a bad manner.
• So, what I have though is I would compile after every change. The complier will scream out if there is syntactical errors and missing definitions.
• Moreover, I will run unit test and test with that there is no run time error also and the behavior of code remains the same.
• Rest, Google, my best friend who knows everything is always with me and will help me in every situation.

Deliverables

• Modernize the C++.
• Improve library functionalities
• Make code more readable and maintainable
• Document it using doxygen system
• Create Reusable code.

Importance of the Project:

• Improving Design :As people change the code to realize short term goals, the code will lose its structure and program will decay.
• Makes Software Easier to Understand : Still compiler taking a few more overheads and delivering output a few milliseconds later is not of huge concern to most of us. But, what worries us is that a new developer will have to spend a week figuring out the part he wants to change which would be actually job of an hour if the code was well managed.
• Easier to add new Features

Time availability:

• My availability for the project would be possible for the specific GSoC period as I would be having my summer break from 1st May to last week of July. Since in August the new semester would have just begun, I would be able to spare enough time to work on the project as I am not involved in anything else which would be a hindrance.
• I will also work on Sundays if needed needed to cope-up in-case if I am unable to meet with my development schedule due to unavoidable circumstances.

Even after GSoC period I will get enough time to continue contributing to BRD-CAL.

Development schedule:

//* Pre-GSoC Period */

• • April 19- 22 : Downloaded Source-code and made one initial patch.
  • April 23-30 : Final End-Semester Exams at University.
  • May 1-3 : Submit some more patches to showcase my work.
  • May 4-21: Ensure Build Environment is working fine, stay in constant contact with the mentor to discuss efficient ways and asking them questions and make some more patches.

/* GSoC period Starts */

• May 21- June 14 : (PHASE I: Analysis and Design Period)
  • Getting familiar with the code
  • Examine the existing STEPcode repo at https://github.com/stepcode/stepcode and create a list of tasks that need to be done.
  • At the end of this period : A finalized plan to proceed for the development of the library.

• June 15 – August 15 (PHASE II: Development Phase)
  • June 15 – July 7 - Refactoring and Coding begins and testing it with step-g convertor.
  • July 7 – July 14 - bugs fixing, review to be ready for submitting.
  • July 15 -July 21 -Organizing source code documentation in the step libraries to work well with doxygen.
  • July 15 –24 - submitting and some more review and updating if it is necessary and making mid-term report.
  • July 25 – August 15 - modifying other files in the source code that gets afftected due to changes in STEP library.
  • At the end of this period : A complete library with all functionalities and all of them having been tested at unit level.

• August 16- September 27 (PHASE III :Testing, Cleaning and Wrapping Up)
  • August 16 – August 20 - System Level testing for library at multiple platforms.
  • August 21-September 9 - bugs fixing, review to be ready for submitting the final result.
  • September 10- 22 -Pencils down ,Code clean up , Documentation (wiki pages)
  • Sept. 23 – 27- Final evaluation and Submit code to Google
  • At the end of this period: Deliverable mentioned would be successfully be completed.

My preparation for the Project:

• Joined IRC channel #brlcad
• I have mailed in the mailing list of BRL-CAD talking about my interests and planning for near future.
• Surfed through previous year projects where I found one similar project. I am also in contacting with that candidate who would guide me and share her experience with me.
• Cloned the source-code into my system.
• Opened some src files, saw some codes and found huge cod repition over there. *As my first step, I had modified the file /src/libbn/plot3 and reduced some amount of code.
• I didn't have previous experience with SVN version control system. Made an account on sourceforge.net and submitted my first patch.
• <Right now>I am checking out STEP Libraries and how it functions.
• Due to the burden of final exams I am afraid that I couldn't work to my maximum potential till 30th April. But from 1st May to May 3rd, I am planning to submit some more patches to show my work.

Why me?

• The reason why I am a suitable candidate for "Code Refactoring" project is because most importantly, I love programming in C and C++ and figuring others code looks quite fascinating job to me.
• Moreover, I had won 3rd and 1st position respectively in "i-code and C-debugging contest" organized by IEEE as a part of I-Fest at DA-IICT in 2012 and 2011 respectively.
• I have been certified as excellent C and C++ coder with A++ grade by Centre for Development and Advanced Computing(CDAC), Pune, India.

Why BRL-CAD?

• The code is entirely written in C, the programming language in which I am the stongest.
• Also, I chose BRL-CAD because I think it's great to work on such a powerful Open Source modeling system.

I promise that if given this opportunity, I will work with full dedication, give my 100% efforts, leave no stones unturned and reduce the code and make it more readable.