ಟಿ. ಜಿ. ಶ್ರೀನಿಧಿ
ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮುಗಿದ ತಕ್ಷಣ ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿಯ ಕೆಲಸವೇನೂ ಮುಗಿಯುವುದಿಲ್ಲ. ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯ (ಟೆಸ್ಟಿಂಗ್) ಕಾರಣದಿಂದಲೋ, ನಂತರದ ದಿನಗಳಲ್ಲಿ ನಿರ್ವಹಣೆಗಾಗಿಯೋ (ಮೇಂಟೆನೆನ್ಸ್) ಪ್ರೋಗ್ರಾಮುಗಳನ್ನು ಬದಲಾಯಿಸುವ ಕೆಲಸ ನಡೆದೇ ಇರುತ್ತದೆ. ಈ ಪ್ರಕ್ರಿಯೆ ಸಾಕಷ್ಟು ದೀರ್ಘಕಾಲ ನಡೆಯುವಂಥದ್ದು: ಏಕೆಂದರೆ ತಂತ್ರಾಂಶಗಳು ದಶಕಗಳ ಕಾಲ ಬಳಕೆಯಲ್ಲಿ ಉಳಿದುಕೊಳ್ಳುವುದು ಕಂಪ್ಯೂಟರ್ ಪ್ರಪಂಚದಲ್ಲಿ ಅಪರೂಪದ ಸಂಗತಿಯೇನಲ್ಲ.
ಇಷ್ಟೆಲ್ಲ ದೀರ್ಘಕಾಲ ತಂತ್ರಾಂಶಗಳು ಬಳಕೆಯಾಗುತ್ತವೆ ಎಂದರೆ ಆ ಅವಧಿಯಲ್ಲಿ ಯಾವಾಗ ಬೇಕಾದರೂ ತಂತ್ರಾಂಶದಲ್ಲಿನ ಪ್ರೋಗ್ರಾಮುಗಳನ್ನು ಬದಲಿಸಬೇಕಾಗಿ ಬರಬಹುದು. ಆದರೆ ಇಷ್ಟೆಲ್ಲ ದೀರ್ಘಕಾಲ ಒಬ್ಬನೇ ವ್ಯಕ್ತಿ ಆ ಬದಲಾವಣೆಗಳ ಮೇಲ್ವಿಚಾರಣೆ ನೋಡಿಕೊಳ್ಳುತ್ತಾನೆ ಎನ್ನುವಂತಿಲ್ಲ.
ಅರೆ, ಪ್ರೋಗ್ರಾಮನ್ನು ಬದಲಿಸಬೇಕಾದ ಅಗತ್ಯಕ್ಕೂ ಆ ಬದಲಾವಣೆಗಳನ್ನು ಯಾರು ಮಾಡುತ್ತಾರೆ ಎನ್ನುವುದಕ್ಕೂ ಏನು ಸಂಬಂಧ?
ಸಂಬಂಧ ಬಹಳ ಸರಳವಾದದ್ದು.
ಬೆಂಗಳೂರಿನಿಂದ ಮೈಸೂರಿಗೆ ಹೋಗುವುದು ಹೇಗೆ? ರೈಲಿನಲ್ಲಿ ಹೋಗಬಹುದು, ವಿಮಾನದಲ್ಲಿ ಹೋಗಬಹುದು, ಬಸ್ಸಿನಲ್ಲಿ ಹೋಗಬಹುದು ಅಥವಾ ಕಾರು ಇಲ್ಲವೇ ಬೈಕಿನಲ್ಲಿ ಹೋಗಬಹುದು (ಇದೆಲ್ಲ ಬೇಡವೆಂದರೆ ಸೈಕಲ್ ಆದರೂ ನಡೆದೀತು). ಮದ್ದೂರು-ಮಂಡ್ಯ ಮಾರ್ಗವಾಗಿ ಹೋಗಬಹುದು ಇಲ್ಲವೇ ಕನಕಪುರ ಮಾರ್ಗವಾಗಿಯೂ ಹೋಗಬಹುದು.
ಪ್ರೋಗ್ರಾಮ್ ಬರೆಯುವ ಕೆಲಸವೂ ಹೀಗೆಯೇ. ಬಹುತೇಕ ಪ್ರೋಗ್ರಾಮುಗಳನ್ನು ಹಲವಾರು ರೀತಿಯಲ್ಲಿ ಬರೆಯುವುದು ಸಾಧ್ಯ. ಪ್ರೋಗ್ರಾಮಿನ ತರ್ಕ (ಲಾಜಿಕ್) ಅದನ್ನು ಬರೆದವರ ಯೋಚನಾಶೈಲಿಗೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ ಎಂದರೂ ಸರಿಯೇ.
ಹಾಗಾಗಿಯೇ ಪ್ರೋಗ್ರಾಮಿನಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವುದು ಮೂಲತಃ ಅದನ್ನು ಬರೆದವರಿಗೆ ಬಹಳ ಸುಲಭದ ಕೆಲಸ. ಆದರೆ ಪ್ರೋಗ್ರಾಮ್ ಬರೆದು ಎಷ್ಟೋ ಕಾಲದ ನಂತರ ಅದನ್ನು ಬದಲಿಸಬೇಕಾಗಿ ಬಂದರೆ ಏನು ಮಾಡುವುದು? ಸಾಫ್ಟ್‌ವೇರ್ ಸಿದ್ಧಪಡಿಸಿದ ಸಂಸ್ಥೆಯಲ್ಲಿ ಕೆಲಸಮಾಡುತ್ತಿದ್ದ ವ್ಯಕ್ತಿ ಆ ವೇಳೆಗೆ ಕೆಲಸ ಬಿಟ್ಟುಹೋಗಿರಬಹುದು. ಪ್ರೋಗ್ರಾಮ್ ಬರೆದ ವ್ಯಕ್ತಿಯನ್ನೇ ಒಂದುವೇಳೆ ಹುಡುಕಿ ಕರೆತಂದೆವೆಂದು ಇಟ್ಟುಕೊಂಡರೂ ಅಷ್ಟು ಕಾಲದ ಹಿಂದೆ ನಾನೇನು ಬರೆದಿದ್ದೆ ಎಂದು ಆ ವ್ಯಕ್ತಿಗೆ ನೆನಪಿರಬೇಕೆಂದೇನೂ ಇಲ್ಲ.
ಪ್ರೋಗ್ರಾಮಿನ ತರ್ಕ ಯಾರು ಯಾವಾಗ ನೋಡಿದರೂ ಅರ್ಥವಾಗುವಂತಿರಬೇಕು ಎನ್ನುವುದು ಇದಕ್ಕೇ. ಪ್ರೋಗ್ರಾಮಿನ ಯಾವ ಭಾಗವನ್ನು ಯಾವ ಉದ್ದೇಶದಿಂದ ಬರೆಯಲಾಗಿದೆ, ಅದರಲ್ಲಿ ಅಳವಡಿಸಿರುವ ತರ್ಕ ಏನು ಎನ್ನುವ ವಿಷಯ ಸುಲಭಕ್ಕೆ ಅರ್ಥವಾದರೆ ಅದನ್ನು ಬದಲಿಸುವ ಕೆಲಸ - ಯಾರಿಗೇ ಆದರೂ - ಸುಲಭ.
ಪ್ರೋಗ್ರಾಮಿನ ತರ್ಕ ಕಂಪ್ಯೂಟರಿಗೆ ಅರ್ಥವಾಗುವಂತಿರಬೇಕು ಎನ್ನುವುದೇನೋ ಸರಿ. ಆದರೆ ಅದನ್ನು ಬೇರೊಬ್ಬ ಪ್ರೋಗ್ರಾಮರ್‌ಗೆ ಅರ್ಥಮಾಡಿಸುವುದು ಹೇಗೆ?
ಇದಕ್ಕೆ ಸುಲಭ ಸೂತ್ರವೆಂದರೆ ಪ್ರೋಗ್ರಾಮಿನ ರಚನೆಯನ್ನು ಆದಷ್ಟೂ ಸರಳವಾಗಿ ಉಳಿಸಿಕೊಳ್ಳುವುದು. ಪ್ರೋಗ್ರಾಮಿನ ಉದ್ದೇಶವನ್ನು ನಿರ್ದಿಷ್ಟ ಹಂತಗಳಾಗಿ ವಿಭಜಿಸಿ ಆ ತರ್ಕವನ್ನು ನಮ್ಮ ಪ್ರೋಗ್ರಾಮಿನ ರಚನೆಯಲ್ಲೂ ಅಳವಡಿಸಿಕೊಂಡರೆ (ಉದಾ: ಪದೇಪದೇ ಮಾಡಬೇಕಾದ ಕೆಲಸಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಉಪಪ್ರೋಗ್ರಾಮುಗಳನ್ನು ರಚಿಸಿ ಅವನ್ನೇ ಮತ್ತೆಮತ್ತೆ ಬಳಸುವುದು) ಒಟ್ಟಾರೆ ಪ್ರೋಗ್ರಾಮನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಕೊಂಚಮಟ್ಟಿಗೆ ಸುಲಭವಾಗುತ್ತದೆ. ತರ್ಕದ ಹರಿವು ಸ್ಪಷ್ಟವಾಗುವಂತೆ ಪ್ರೋಗ್ರಾಮ್ ಕಡತದ ವಿನ್ಯಾಸವನ್ನು (ಫಾರ್ಮ್ಯಾಟಿಂಗ್) ರೂಪಿಸುವುದೂ ಅದನ್ನು ಸುಲಭವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ಸಹಕಾರಿ.
ಇವೆಲ್ಲದರ ಜೊತೆಗೆ ಪ್ರೋಗ್ರಾಮಿನ ಜೊತೆಯಲ್ಲಿ ನಾವು ಏನೆಲ್ಲ ವಿವರಗಳನ್ನು ಕೊಟ್ಟಿದ್ದೇವೆ ಎನ್ನುವುದೂ ಮುಖ್ಯವೇ.
ನಾವು ಬರೆದ ಪ್ರೋಗ್ರಾಮಿನಲ್ಲಿ ಕಂಪ್ಯೂಟರಿಗೆ ಅರ್ಥವಾಗುವ ಆದೇಶಗಳನ್ನು ಬರೆದಂತೆ ಆ ಕಡತವನ್ನು ನೋಡುವ ಬೇರೊಬ್ಬ ಪ್ರೋಗ್ರಾಮರ್‌ಗೆ ಹೆಚ್ಚು ಶ್ರಮವಿಲ್ಲದೆ ಅರ್ಥವಾಗುವಂತಹ ಮಾಹಿತಿಯನ್ನೂ ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ. ಗಣಿತದ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಲೆಕ್ಕ ಬಿಡಿಸುವ ಜೊತೆಗೆ ಅದನ್ನು ಹೇಗೆ ಬಿಡಿಸಿದೆವೆಂಬ ಅಂಶವನ್ನೂ ವಿವರಿಸುತ್ತೇವಲ್ಲ, ಇದೂ ಹಾಗೆಯೇ ಎನ್ನಬಹುದು.
ಪ್ರೋಗ್ರಾಮಿನ ಕಾರ್ಯಾಚರಣೆಗೆ ಅನಗತ್ಯವಾದ, ಆದರೆ ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ಬಹಳ ಮಹತ್ವದ ಇಂತಹ ಮಾಹಿತಿಯನ್ನು 'ಕಮೆಂಟು'ಗಳೆಂದು ಕರೆಯುತ್ತಾರೆ. ಪ್ರೋಗ್ರಾಮಿನ ಉದ್ದೇಶ ಏನು, ಅದರ ಯಾವುದೋ ನಿರ್ದಿಷ್ಟ ಭಾಗ ಏನು ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಪ್ರೋಗ್ರಾಮಿನ ಈ ಭಾಗವನ್ನು ಹೀಗೆಯೇ ಬರೆದಿರುವುದು ಏಕೆ - ಮುಂತಾದ ಅನೇಕ ಪ್ರಶ್ನೆಗಳಿಗೆ ಕಮೆಂಟುಗಳ ರೂಪದ ಉತ್ತರ ಬರೆದಿಟ್ಟರೆ ಆ ಪ್ರೋಗ್ರಾಮನ್ನು ನೋಡುವ ಬೇರೆಯ ಪ್ರೋಗ್ರಾಮರುಗಳಿಗೆ ಖಂಡಿತಾ ಸಹಾಯವಾಗುತ್ತದೆ. ನಾವೇ ಬರೆದ ಪ್ರೋಗ್ರಾಮನ್ನು ನಾಲ್ಕಾರು ತಿಂಗಳ ನಂತರ ನೋಡಿ ಇದನ್ನು ಹೀಗೇಕೆ ಬರೆದೆನೆಂದು ತಲೆಕೆರೆದುಕೊಳ್ಳದೆ ಇರಬೇಕಾದರೂ ಕಮೆಂಟುಗಳು ಬೇಕು.
ಕಮೆಂಟುಗಳನ್ನು ಸೇರಿಸುವ ವಿಧಾನ ಬೇರೆಬೇರೆ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ ಬೇರೆಬೇರೆ ರೀತಿಯಾಗಿರುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಕಮೆಂಟುಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಲೇಖನಚಿಹ್ನೆಗಳ ನಂತರ (', //), ಅಥವಾ ನಡುವೆ (/*, */ ಇತ್ಯಾದಿ) ಬರೆಯುವುದು ಸಂಪ್ರದಾಯ. ಪ್ರೋಗ್ರಾಮಿನಲ್ಲಿರುವ ಆದೇಶಗಳನ್ನೆಲ್ಲ ಪಾಲಿಸುವ ಕಂಪ್ಯೂಟರ್ ಈ ಚಿಹ್ನೆಗಳನ್ನು ಗುರುತಿಸಿ ಅವುಗಳ ಜೊತೆಯಲ್ಲಿ ಬರೆದಿರುವುದನ್ನೆಲ್ಲ ಸಾರಾಸಗಟಾಗಿ ಉಪೇಕ್ಷಿಸುವುದರಿಂದ ಕಮೆಂಟುಗಳು ಪ್ರೋಗ್ರಾಮ್ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
ಪ್ರೋಗ್ರಾಮಿನಲ್ಲಿ ಕಮೆಂಟುಗಳಿದ್ದರೆ ಅನುಕೂಲ ಎಂದಮಾತ್ರಕ್ಕೆ ಅತಿಯಾಗಿ ಕಮೆಂಟುಗಳನ್ನು ಬರೆಯುವುದೂ ಸರಿಯಲ್ಲ. ವಿಶೇಷ ಅಂಶಗಳೇನೂ ಇಲ್ಲದ ಭಾಗಗಳಿಗೂ ಕಮೆಂಟು ಬರೆಯುವುದರಿಂದ ಸಮಯ ವ್ಯರ್ಥವಾಗುತ್ತದೆ ಅಷ್ಟೆ. 'ಎ = ಬಿ + ಸಿ' ಎನ್ನುವುದನ್ನು 'ಬಿ' ಮತ್ತು 'ಸಿ' ಕೂಡಿಸಿ 'ಎ'ನಲ್ಲಿ ಇರಿಸು ಎಂಬ ಕಮೆಂಟ್ ಇಲ್ಲದಿದ್ದರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸಾಧ್ಯವಿದೆಯಲ್ಲ!
ಇದಲ್ಲದೆ ನಮ್ಮ ಪ್ರೋಗ್ರಾಮಿಗೆ ಕಮೆಂಟುಗಳನ್ನು ಸೇರಿಸುವಾಗ ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳನ್ನು ಪಾಲಿಸುವುದು ಒಳ್ಳೆಯದು. ಪ್ರೋಗ್ರಾಮನ್ನು ಬರೆದದ್ದು ಅಥವಾ ಬದಲಿಸಿದ್ದು ಯಾರು, ಯಾವತ್ತು, ಮತ್ತು ಆ ಬದಲಾವಣೆಗೆ ಕಾರಣವೇನು ಎಂಬಂತಹ ಅಂಶಗಳನ್ನು ಎಲ್ಲೆಡೆಯೂ ಏಕಪ್ರಕಾರವಾಗಿ ಸೇರಿಸಿದರೆ ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸುಲಭವಾಗುತ್ತದೆ. ಹಾಗೆ ಮಾಡದ ಪಕ್ಷದಲ್ಲಿ ಪ್ರೋಗ್ರಾಮನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ಕಮೆಂಟುಗಳು ನೆರವಾಗುವ ಬದಲು ಕಮೆಂಟುಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲಿಕ್ಕೇ ನೆರವು ಹುಡುಕಬೇಕಾಗುತ್ತದೆ ಅಷ್ಟೆ!
ಏಪ್ರಿಲ್ ೧೮, ೨೦೧೪ರ ಉದಯವಾಣಿಯಲ್ಲಿ ಪ್ರಕಟವಾದ ಲೇಖನ
ಇಷ್ಟೆಲ್ಲ ದೀರ್ಘಕಾಲ ತಂತ್ರಾಂಶಗಳು ಬಳಕೆಯಾಗುತ್ತವೆ ಎಂದರೆ ಆ ಅವಧಿಯಲ್ಲಿ ಯಾವಾಗ ಬೇಕಾದರೂ ತಂತ್ರಾಂಶದಲ್ಲಿನ ಪ್ರೋಗ್ರಾಮುಗಳನ್ನು ಬದಲಿಸಬೇಕಾಗಿ ಬರಬಹುದು. ಆದರೆ ಇಷ್ಟೆಲ್ಲ ದೀರ್ಘಕಾಲ ಒಬ್ಬನೇ ವ್ಯಕ್ತಿ ಆ ಬದಲಾವಣೆಗಳ ಮೇಲ್ವಿಚಾರಣೆ ನೋಡಿಕೊಳ್ಳುತ್ತಾನೆ ಎನ್ನುವಂತಿಲ್ಲ.
ಅರೆ, ಪ್ರೋಗ್ರಾಮನ್ನು ಬದಲಿಸಬೇಕಾದ ಅಗತ್ಯಕ್ಕೂ ಆ ಬದಲಾವಣೆಗಳನ್ನು ಯಾರು ಮಾಡುತ್ತಾರೆ ಎನ್ನುವುದಕ್ಕೂ ಏನು ಸಂಬಂಧ?
ಸಂಬಂಧ ಬಹಳ ಸರಳವಾದದ್ದು.
ಬೆಂಗಳೂರಿನಿಂದ ಮೈಸೂರಿಗೆ ಹೋಗುವುದು ಹೇಗೆ? ರೈಲಿನಲ್ಲಿ ಹೋಗಬಹುದು, ವಿಮಾನದಲ್ಲಿ ಹೋಗಬಹುದು, ಬಸ್ಸಿನಲ್ಲಿ ಹೋಗಬಹುದು ಅಥವಾ ಕಾರು ಇಲ್ಲವೇ ಬೈಕಿನಲ್ಲಿ ಹೋಗಬಹುದು (ಇದೆಲ್ಲ ಬೇಡವೆಂದರೆ ಸೈಕಲ್ ಆದರೂ ನಡೆದೀತು). ಮದ್ದೂರು-ಮಂಡ್ಯ ಮಾರ್ಗವಾಗಿ ಹೋಗಬಹುದು ಇಲ್ಲವೇ ಕನಕಪುರ ಮಾರ್ಗವಾಗಿಯೂ ಹೋಗಬಹುದು.
ಪ್ರೋಗ್ರಾಮ್ ಬರೆಯುವ ಕೆಲಸವೂ ಹೀಗೆಯೇ. ಬಹುತೇಕ ಪ್ರೋಗ್ರಾಮುಗಳನ್ನು ಹಲವಾರು ರೀತಿಯಲ್ಲಿ ಬರೆಯುವುದು ಸಾಧ್ಯ. ಪ್ರೋಗ್ರಾಮಿನ ತರ್ಕ (ಲಾಜಿಕ್) ಅದನ್ನು ಬರೆದವರ ಯೋಚನಾಶೈಲಿಗೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ ಎಂದರೂ ಸರಿಯೇ.
ಹಾಗಾಗಿಯೇ ಪ್ರೋಗ್ರಾಮಿನಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವುದು ಮೂಲತಃ ಅದನ್ನು ಬರೆದವರಿಗೆ ಬಹಳ ಸುಲಭದ ಕೆಲಸ. ಆದರೆ ಪ್ರೋಗ್ರಾಮ್ ಬರೆದು ಎಷ್ಟೋ ಕಾಲದ ನಂತರ ಅದನ್ನು ಬದಲಿಸಬೇಕಾಗಿ ಬಂದರೆ ಏನು ಮಾಡುವುದು? ಸಾಫ್ಟ್‌ವೇರ್ ಸಿದ್ಧಪಡಿಸಿದ ಸಂಸ್ಥೆಯಲ್ಲಿ ಕೆಲಸಮಾಡುತ್ತಿದ್ದ ವ್ಯಕ್ತಿ ಆ ವೇಳೆಗೆ ಕೆಲಸ ಬಿಟ್ಟುಹೋಗಿರಬಹುದು. ಪ್ರೋಗ್ರಾಮ್ ಬರೆದ ವ್ಯಕ್ತಿಯನ್ನೇ ಒಂದುವೇಳೆ ಹುಡುಕಿ ಕರೆತಂದೆವೆಂದು ಇಟ್ಟುಕೊಂಡರೂ ಅಷ್ಟು ಕಾಲದ ಹಿಂದೆ ನಾನೇನು ಬರೆದಿದ್ದೆ ಎಂದು ಆ ವ್ಯಕ್ತಿಗೆ ನೆನಪಿರಬೇಕೆಂದೇನೂ ಇಲ್ಲ.
ಪ್ರೋಗ್ರಾಮಿನ ತರ್ಕ ಯಾರು ಯಾವಾಗ ನೋಡಿದರೂ ಅರ್ಥವಾಗುವಂತಿರಬೇಕು ಎನ್ನುವುದು ಇದಕ್ಕೇ. ಪ್ರೋಗ್ರಾಮಿನ ಯಾವ ಭಾಗವನ್ನು ಯಾವ ಉದ್ದೇಶದಿಂದ ಬರೆಯಲಾಗಿದೆ, ಅದರಲ್ಲಿ ಅಳವಡಿಸಿರುವ ತರ್ಕ ಏನು ಎನ್ನುವ ವಿಷಯ ಸುಲಭಕ್ಕೆ ಅರ್ಥವಾದರೆ ಅದನ್ನು ಬದಲಿಸುವ ಕೆಲಸ - ಯಾರಿಗೇ ಆದರೂ - ಸುಲಭ.
ಪ್ರೋಗ್ರಾಮಿನ ತರ್ಕ ಕಂಪ್ಯೂಟರಿಗೆ ಅರ್ಥವಾಗುವಂತಿರಬೇಕು ಎನ್ನುವುದೇನೋ ಸರಿ. ಆದರೆ ಅದನ್ನು ಬೇರೊಬ್ಬ ಪ್ರೋಗ್ರಾಮರ್‌ಗೆ ಅರ್ಥಮಾಡಿಸುವುದು ಹೇಗೆ?
ಇದಕ್ಕೆ ಸುಲಭ ಸೂತ್ರವೆಂದರೆ ಪ್ರೋಗ್ರಾಮಿನ ರಚನೆಯನ್ನು ಆದಷ್ಟೂ ಸರಳವಾಗಿ ಉಳಿಸಿಕೊಳ್ಳುವುದು. ಪ್ರೋಗ್ರಾಮಿನ ಉದ್ದೇಶವನ್ನು ನಿರ್ದಿಷ್ಟ ಹಂತಗಳಾಗಿ ವಿಭಜಿಸಿ ಆ ತರ್ಕವನ್ನು ನಮ್ಮ ಪ್ರೋಗ್ರಾಮಿನ ರಚನೆಯಲ್ಲೂ ಅಳವಡಿಸಿಕೊಂಡರೆ (ಉದಾ: ಪದೇಪದೇ ಮಾಡಬೇಕಾದ ಕೆಲಸಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಉಪಪ್ರೋಗ್ರಾಮುಗಳನ್ನು ರಚಿಸಿ ಅವನ್ನೇ ಮತ್ತೆಮತ್ತೆ ಬಳಸುವುದು) ಒಟ್ಟಾರೆ ಪ್ರೋಗ್ರಾಮನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಕೊಂಚಮಟ್ಟಿಗೆ ಸುಲಭವಾಗುತ್ತದೆ. ತರ್ಕದ ಹರಿವು ಸ್ಪಷ್ಟವಾಗುವಂತೆ ಪ್ರೋಗ್ರಾಮ್ ಕಡತದ ವಿನ್ಯಾಸವನ್ನು (ಫಾರ್ಮ್ಯಾಟಿಂಗ್) ರೂಪಿಸುವುದೂ ಅದನ್ನು ಸುಲಭವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ಸಹಕಾರಿ.
ಇವೆಲ್ಲದರ ಜೊತೆಗೆ ಪ್ರೋಗ್ರಾಮಿನ ಜೊತೆಯಲ್ಲಿ ನಾವು ಏನೆಲ್ಲ ವಿವರಗಳನ್ನು ಕೊಟ್ಟಿದ್ದೇವೆ ಎನ್ನುವುದೂ ಮುಖ್ಯವೇ.
ನಾವು ಬರೆದ ಪ್ರೋಗ್ರಾಮಿನಲ್ಲಿ ಕಂಪ್ಯೂಟರಿಗೆ ಅರ್ಥವಾಗುವ ಆದೇಶಗಳನ್ನು ಬರೆದಂತೆ ಆ ಕಡತವನ್ನು ನೋಡುವ ಬೇರೊಬ್ಬ ಪ್ರೋಗ್ರಾಮರ್‌ಗೆ ಹೆಚ್ಚು ಶ್ರಮವಿಲ್ಲದೆ ಅರ್ಥವಾಗುವಂತಹ ಮಾಹಿತಿಯನ್ನೂ ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ. ಗಣಿತದ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಲೆಕ್ಕ ಬಿಡಿಸುವ ಜೊತೆಗೆ ಅದನ್ನು ಹೇಗೆ ಬಿಡಿಸಿದೆವೆಂಬ ಅಂಶವನ್ನೂ ವಿವರಿಸುತ್ತೇವಲ್ಲ, ಇದೂ ಹಾಗೆಯೇ ಎನ್ನಬಹುದು.
ಪ್ರೋಗ್ರಾಮಿನ ಕಾರ್ಯಾಚರಣೆಗೆ ಅನಗತ್ಯವಾದ, ಆದರೆ ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ಬಹಳ ಮಹತ್ವದ ಇಂತಹ ಮಾಹಿತಿಯನ್ನು 'ಕಮೆಂಟು'ಗಳೆಂದು ಕರೆಯುತ್ತಾರೆ. ಪ್ರೋಗ್ರಾಮಿನ ಉದ್ದೇಶ ಏನು, ಅದರ ಯಾವುದೋ ನಿರ್ದಿಷ್ಟ ಭಾಗ ಏನು ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಪ್ರೋಗ್ರಾಮಿನ ಈ ಭಾಗವನ್ನು ಹೀಗೆಯೇ ಬರೆದಿರುವುದು ಏಕೆ - ಮುಂತಾದ ಅನೇಕ ಪ್ರಶ್ನೆಗಳಿಗೆ ಕಮೆಂಟುಗಳ ರೂಪದ ಉತ್ತರ ಬರೆದಿಟ್ಟರೆ ಆ ಪ್ರೋಗ್ರಾಮನ್ನು ನೋಡುವ ಬೇರೆಯ ಪ್ರೋಗ್ರಾಮರುಗಳಿಗೆ ಖಂಡಿತಾ ಸಹಾಯವಾಗುತ್ತದೆ. ನಾವೇ ಬರೆದ ಪ್ರೋಗ್ರಾಮನ್ನು ನಾಲ್ಕಾರು ತಿಂಗಳ ನಂತರ ನೋಡಿ ಇದನ್ನು ಹೀಗೇಕೆ ಬರೆದೆನೆಂದು ತಲೆಕೆರೆದುಕೊಳ್ಳದೆ ಇರಬೇಕಾದರೂ ಕಮೆಂಟುಗಳು ಬೇಕು.
ಕಮೆಂಟುಗಳನ್ನು ಸೇರಿಸುವ ವಿಧಾನ ಬೇರೆಬೇರೆ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ ಬೇರೆಬೇರೆ ರೀತಿಯಾಗಿರುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಕಮೆಂಟುಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಲೇಖನಚಿಹ್ನೆಗಳ ನಂತರ (', //), ಅಥವಾ ನಡುವೆ (/*, */ ಇತ್ಯಾದಿ) ಬರೆಯುವುದು ಸಂಪ್ರದಾಯ. ಪ್ರೋಗ್ರಾಮಿನಲ್ಲಿರುವ ಆದೇಶಗಳನ್ನೆಲ್ಲ ಪಾಲಿಸುವ ಕಂಪ್ಯೂಟರ್ ಈ ಚಿಹ್ನೆಗಳನ್ನು ಗುರುತಿಸಿ ಅವುಗಳ ಜೊತೆಯಲ್ಲಿ ಬರೆದಿರುವುದನ್ನೆಲ್ಲ ಸಾರಾಸಗಟಾಗಿ ಉಪೇಕ್ಷಿಸುವುದರಿಂದ ಕಮೆಂಟುಗಳು ಪ್ರೋಗ್ರಾಮ್ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
ಪ್ರೋಗ್ರಾಮಿನಲ್ಲಿ ಕಮೆಂಟುಗಳಿದ್ದರೆ ಅನುಕೂಲ ಎಂದಮಾತ್ರಕ್ಕೆ ಅತಿಯಾಗಿ ಕಮೆಂಟುಗಳನ್ನು ಬರೆಯುವುದೂ ಸರಿಯಲ್ಲ. ವಿಶೇಷ ಅಂಶಗಳೇನೂ ಇಲ್ಲದ ಭಾಗಗಳಿಗೂ ಕಮೆಂಟು ಬರೆಯುವುದರಿಂದ ಸಮಯ ವ್ಯರ್ಥವಾಗುತ್ತದೆ ಅಷ್ಟೆ. 'ಎ = ಬಿ + ಸಿ' ಎನ್ನುವುದನ್ನು 'ಬಿ' ಮತ್ತು 'ಸಿ' ಕೂಡಿಸಿ 'ಎ'ನಲ್ಲಿ ಇರಿಸು ಎಂಬ ಕಮೆಂಟ್ ಇಲ್ಲದಿದ್ದರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸಾಧ್ಯವಿದೆಯಲ್ಲ!
ಇದಲ್ಲದೆ ನಮ್ಮ ಪ್ರೋಗ್ರಾಮಿಗೆ ಕಮೆಂಟುಗಳನ್ನು ಸೇರಿಸುವಾಗ ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳನ್ನು ಪಾಲಿಸುವುದು ಒಳ್ಳೆಯದು. ಪ್ರೋಗ್ರಾಮನ್ನು ಬರೆದದ್ದು ಅಥವಾ ಬದಲಿಸಿದ್ದು ಯಾರು, ಯಾವತ್ತು, ಮತ್ತು ಆ ಬದಲಾವಣೆಗೆ ಕಾರಣವೇನು ಎಂಬಂತಹ ಅಂಶಗಳನ್ನು ಎಲ್ಲೆಡೆಯೂ ಏಕಪ್ರಕಾರವಾಗಿ ಸೇರಿಸಿದರೆ ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸುಲಭವಾಗುತ್ತದೆ. ಹಾಗೆ ಮಾಡದ ಪಕ್ಷದಲ್ಲಿ ಪ್ರೋಗ್ರಾಮನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ಕಮೆಂಟುಗಳು ನೆರವಾಗುವ ಬದಲು ಕಮೆಂಟುಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲಿಕ್ಕೇ ನೆರವು ಹುಡುಕಬೇಕಾಗುತ್ತದೆ ಅಷ್ಟೆ!
ಏಪ್ರಿಲ್ ೧೮, ೨೦೧೪ರ ಉದಯವಾಣಿಯಲ್ಲಿ ಪ್ರಕಟವಾದ ಲೇಖನ
ಕಾಮೆಂಟ್‌ಗಳಿಲ್ಲ:
ಕಾಮೆಂಟ್‌ ಪೋಸ್ಟ್‌ ಮಾಡಿ