In times past, most people coded on a terminal that was 80 characters wide. In many languages this has become, if not holy then close to it.
But now many people have 20"+ monitors (or dual monitors), so screen real estate isn't as prime as it once was.
So my question is this: in Visual Basic code, should code be limited to 80 characters, should there be no limit, or is it really a subjective thing, dependent on where you work and your own preferences?
I think it is subjective, but not completely. Limiting code to 80 characters will make it more readable. This is the reason that newspapers have their articles in columns. It is easier to read text if it doesn't get much longer than 70 characters or so. I believe that people have done usability studies on this, but I don't have the references to back that up.
So, again, it is subjective, and situation-dependent, but longer lines are harder to read. So I try to stay within 80 characters even though I don't have to do so.
Humans read and comprehend fastest, when there are 40-70 characters per line of prose (approx. 10 words per line). I think something similar will apply to code.
Do what is most comfortable and works best for you. This is pretty much a universal truth for everything.
Subjective, but within some constraints (for example, if everyone is issued a monitor with size X). We use 110 characters, and it works for us even though some of us use widescreen monitors rotated to portrait.
I know a number of people who are remarkably fastidious about 80 character lines. As an arbitrary standard it's not bad, but if nobody is nagging you make it whatever length you feel comfortable with.
Approximate 80 characters is what I'd recommend. What I do with the extra monitor realistate is have 2 code files side by side. And the 2nd screen gets all the toolbars, property windows, and a 3rd code or interface layout window.
I'm going to go against the grain here, but I say don't limit yourself. If you are abbreviating class/function/variable names for the sake of saving space, you are just taking your code one more step away from being quickly grok'd. I think everyone should hop on the widescreen bandwagon anyway.
A problem is sometimes people may code in a window that isn't full screen, and then have to scroll, or the code wraps automatically.
Having to scroll left and right to read code is horrible.
I've had the issue with comments in code.. either limiting them in number of char wide.. or putting them in a different file!
Related
I wanted to run some captcha possibities past people to see if they are easily by passed by bots etc.
What if colors were used - eg: there is a string of 10 characters are you ask people to type the red characters of where there are 5? Easy to bypass?
I've noticed a captcha on plentyoffish that involves typing in the characters under the circles. This seems a touch more complex - would this be more challenging for bots?
The other idea I was thinking was putting the requirement in an image as well meaning like in no. 1 above - you can put "type the red characters" in an image and this could change with different colors. Any value here?
Interested in what people think.
cheers
Colours are easy to bypass. A bot just takes the red channel and gets the answer. It is even easier than choosing between many possible solutions. The same applies to any noise that has another colour than the letters the user needs to find.
Symbols that don't touch the letters are very easy to ignore. Why would a bot even look at those circles that probably always stay at the same position? (valid but wasn't asked here)
Identifying circles or other symbols is easier than identifying letters, if one can do the latter, a simple symbol is no challenge.
I think captchas are used too frequently in places where they aren't the best tool. For instance, are you trying to prevent registration spam? Why use a captcha rather than email validation?
What are your intentions and have you considered alternatives to the (relatively ineffective) captcha technology?
As a side note, if you have to use them, I prefer KittyAuth myself :) http://thepcspy.com/kittenauth/#5
Color blind people will have trouble separating red from green letters. People who have trouble reading and understanding descriptions, or have other disabilities may have trouble reading the captchas too.
In some of these, the texts are so mangled that almost everyone has a hard time reading them.
I think captcha's, if used at all, should be quite easy to read. The one with the dots and triangles is doable, although it's a matter of time before someone writes an algorithm to hack them. It is very easy for computers to read this kind too.
The best way to deal with this, is increase moderation. Make your site so that it isn't rewarding to spam it at all. Don't make it the problem of your users.
Also, if you're gonna use captcha's, it may be better to build something yourself than to use common libraries. I've found that these are easier hacked, probably because it is more rewarding to write a captcha solver for something that is used by thhousands of sites.
No matter which CAPTCHA you construct, spammers will find a way to work around it, given enough incentive. Large CAPTCHA services like reCAPTCHA, for instance, get bypassed by outsourcing solving them to cheap labor in India(source).
If you run a small site, your best bet is to make your own mini-CAPTCHA, which asks a simple question. If it isn't a standard question, isn't a standard CAPTCHA module and isn't a large site, it isn't worth it for the spammers to automate bypassing it.
I've been working on a community site for an organization at my university, and we've had trouble with spammers registering, despite us using every CAPTCHA module in the book. As soon as we made our own simple one-question CAPTCHA, all spam stopped. The key to preventing this sort of spam often lies in uniqueness.
I know they are, but my co-worker doesn't believe me. He keeps telling me that Google crawls the inside content and caches it just fine. According to Google, it does crawl them, but doesn't guarantee doing it properly.
Any thoughts why frames are bad for public web sites?
There are various usability and accessibility issues with frames:
link can open in the frame it is enclosed in (e.g. a side pane);
can break the forward/backward navigation;
difficult to bookmark;
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
can break with screen readers and magnifiers (for blind users and visual impaired users);
See http://www.angelfire.com/super/badwebs/ for an example of what not to do.
Frames are more difficult to bookmark and, therefore, more difficult to share with others.
http://www.yourhtmlsource.com/frames/goodorbad.html
IFrames (like HTML tables) are not bad. However, people were abusing them quite a lot, thus giving them the bad name.
IFrames do represent a good concept - single visual representation of documents coming from different sources, while keeping the DOM trees properly separated and isolated.
The problem arises when a script in one of the DOM trees needs to access the elements in another tree. Or when people want to reference the document location, which happens to be the URL of the root document, and fail to realize they need to location of the secondary document.
But the biggest problem with frames is that there are sites that want to encapsulated other sites in frame and trick the user to think they are interacting with the framed site, while in fact interacting with the outer one. This is the primary reason why most websites will employ some form of frame-busting scripts for their login pages.
Update: It's Friday and we need some fun, so here's the (obligatory) link to Jeff's post on frames-busting-busters-busting... :-)
At the beginning ...
The idea behind framesets is great. It's alive and kicking today; check StackOverflow's left side panel, or the header. They are fixed divs, which is basically the same thing as having frames, although a lot more flexible.
The very concept of keeping some part while changing another is simply necessary by the logic of webpages. We need something to stay where it was (typically navigation) while we go through a lot of details in the main area. Framesets served this purpose very well, they were easy to use and fully supported by all browsers, meaning 3 at that time (Netscape, IE, Opera).
Then we scorched the sky
The real, practical problems with frames had nothing to do with their basic concept. Instead, it was us being only human. I followed this whole debate very closely so believe me when I say these were the real charges against frame technology:
Designers hated them. Yes, that was the deadliest punch. Everything looked square and straight. They hated it. They wanted arcs and image backgrounds and rounded borders. Now they have it in CSS3 - guess what, they're drawing squares. #whatever
Programmers had trouble with them. It was inconvenient to follow the logic of frames, and you had to do some extra work. I mean, some. Today it's a lot harder to create AJAX solutions for the same problem, but no one complains. #whatever
Websites could include one another. This was painful for some site owners because they worked hard on something and another fella used it as own content. Later, they invented same origin policy, but it was way after starting to hate frames. Content stealing is still an issue today, absolutely unrelated to whether we have frames or not. #whatever
Back button worked differently. Yes, it was a bit annoying. But it was not the frame concept's fault, again: it was browsers who did this to us. Could have been solved easily, but nah, browsers kept going back one by one, not providing the site a way to implement its own "step back" method, and alas, this is still happening today. #whatever
So instead of coming up with a solution, the world's web developers decided to hate frames. They ditched it, and now we live in a world where there are lots of better solutions - but with a lot more effort. This was not the only feature going thru the hate-ditch-reinvent-love cycle; see vertical centering and flexbox, aka the table tag debate - and it will happen many more times because it's always easier to point fingers at something than to learn why it's great.
I don't hate frames; don't miss them either, they belong to a somewhat outdated world of web. But they were a good solution for something, and there's a chance we'll see something similar in the future just as CSS grids came back to implement what table layouts did before. The same community who hates the old solution will happily embrace the new and tell you why it's not the same at all.
I think this story has a single takeaway:
Implementations come and go.Concepts stay and evolve.
Depending on what you want to do, most things done with frames can be done with CSS. CSS stylesheets are compatible with all MODERN browsers, meaning your website will look the same if using firefox, chrome, or IE 7(with some tweaks). Also backward-compatibility is not a concern as users can view the content even with CSS off (where as a website using frames and without a frameless version of the site will be useless to a user with an old browser), it just won't be as stylized. It's also quite easy to learn, and once you get the hang of it you'll wonder why you haven't learned it in the first place.
I know this is an old thread but..
Been using Frames almost all my life and I think they are great. I still have a few websites using frames and I cannot understand why they are being droppped. Read all of the comments above and disagree with most of them. Problem is most people never bothered to overcome the issues.
Link can open in the frame it is enclosed in (e.g. a side pane);
Yes it can, but if you do it properly it does not matter. Frames can in fact be very useful for this precise reason, as clicking on a link will only refresh the frame the link it pointing to, not the entire webpage. In the days of dialup modems at very slow speeds this used to be extremely useful to save on bandwidth and make webpages appear superfast. Dont forget, there are still people around the world today (albeit not many) that have very limited internet connectivity at very slow speeds. (people on sailboats in the middle of oceans, those die hards that dial into the internet using HF radio. Oh and those that live in war zones that revert back to poor mobile phone signals, or possibly even need to dial into the internet in another contry using their infrared connections on mobile phones via a modem)
can break the forward/backward navigation.
Yes it can, but if you do it properly it wont.
difficult to bookmark
again very easy to overcome, requires very little additional work, but can be easily overcome
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
Already covered by somebody else earlier. Personally I have never even heard of Lynx (apart from the deodarant). In fact it used to be quite useful that pages werent searchable when you did not want to get spammed by bots searching for email addresses... Unfortunately Google or somebody figured out how to do it.
Difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
Clearly whoever wrote this has hardly any experience of using frames. This was exactly why I used frames because I could make it work on any screensize in what some would refer to as Fluid views on modern web design
can break with screen readers and magnifiers (for blind users and visual impaired users);
I suppose it can if screen reading software and maginfiers are cheap and rubbish and dont know what they are doing, probably them that complained about it, but there are others that manage this easily.
The only argument that I think makes sense, is that people were abusing them. Now I would not know how that was done, as I am not in that game, but I suppose it would be easy to use frames to show a copy of lets say a financial payment page inside another another frame which is completely hidden to make it look like the user is on the correct page. Therefore conning users out of their beer tokens. But I believe more modern webbrowsers have been updated to overcome these issues and not allow re-direction where encryption certificates are used.
I can therefore understand why they would want to restrict the use of frames, but dont understand why they need to completely remove what is a pretty good bit of tech. (Bit like saying we are going to stop people from using 0 when they do math as it causes can sometimes cause problems when you add many 0's together.)
I still have some websites that use frames and wonder when I am going to have to re-code them one day.
PS. also note that google calendar and youtube allow one to imbed pages into websites and both of these use iframes.
I'm finding comments on code starting to get annoying. I feel that once you achieve some level of expertise, code is pretty much self documenting. But comments are still a necessity.
What I would like to know if there's such a plugin or IDE with this idea of comments separated from the code. If such a thing doesn't exists, what ideas do you think would work great on a plugin for an IDE like Eclipse?
Take this Python code for example:
def do_something(self, var):
# * 541
...
Then some XML like this:
<comments>
<comment id="541" file="x.py" line="14">This is a comment</comment>
<comments>
Thanks!
I've never heard of such a thing as externalized comments, and I think they'd be slow or easily corrupted, because they'd always have to be updated to stay in sync with the code. Furthermore, if your idea is to completely eliminate them from your view while you're working on your code, you could forget to update them and they could become inaccurate.
A feature you should look into is code folding. Instead of separating the comments into a different file, they're collapsed into a smaller space when you don't want to look at them. Many IDEs implement it (eclipse is one).
Good comments add information, such as why, they don't repeat code, so I don't agree with the premise of the question.
However, to go along with the idea for a moment, I can imagine an IDE that hides comments while you are editing, but storing them separately is a recipe for confusion.
Don't forget that good comments explain intent and consequences, not literally what the code is doing.
Having said that, have you looked at code folding within IDEs ? Eclipse (for one) will collapse comments and hide them. You can reveal them at the press of a button. The comments remain in the code and tied to the relevant sections without any indirection (as you're proposing) so you can view them in any editor/environment.
A quick fix that will work with most editors is to change the syntax highlighting colour scheme to make the comments invisible or barely visible, e.g. light grey text on white background.
If your editor supports multiple colour schemes then you could have one that hides the comments and one that hides everything except comments, then swap between them.
Donald Knuth explored this topic heavily under the title of "literate programming" (which is a fine starting point for Googling). He wrote a program called Weave (or was it Web?) and Tangle which does something like what you ask, but for Pascal code.
I'm afraid the idea never got very far off the ground and I've never heard of anything similar for Python.
These days, there's a community of programmers who believe in writing short methods with names and variable names sufficiently descriptive to make comments (usually) unnecessary. The rest of us just plod along and comment the way we've always done.
UPDATE
I lied! There's something called PyLit, here: http://pylit.berlios.de/literate-programming/index.html . Also, a pretty extensive discussion of the whole thing.
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 8 years ago.
Improve this question
One problem I have with a modern office is that people still tend to create physical copies of digital media (such as program manuals and specifications). I understand that for somethings it is prudent to create a physical copy but many of these physical copies go mostly unused, they just sit on a shelf to maybe one day be flipped through to look up a single piece of information. This is not only a waste of paper but also space and the time that it takes to print out and collate all of these printed documents. It also takes more time to utilize because these items are not capable of being indexed and searched like digital copies.
What are some good ways to promote a paperless environment in the workplace? My company has already implemented a company Wiki. So far the it seems to have made an impact on our use of paper, but some people still think of it as being too much of a hassle.
It won't work for everybody, for sure, but I recently spent a year at a small web development company (under 25 employees) that had no printers and no copiers. Only the owner had one little printer in his locked office. Since they never had any printers or copiers, their work patterns had evolved to not use paper.
This was such a shock to me, as I traditionally work with a lot of paper. I use it to partly control my own workflow -- if it needs to be done, there's a piece of paper (email, Word doc, printed-out bug tracker task) on my desk about it. I'd make notes on the document about the steps I needed to do to complete the task.
Of course, we used a bug tracking/change control system. So, all of my to-do's for my web coding were in that system.
I learned to organize my email better, and to have a good file folder structure in Windows. Ironically, I was more meticulous about deleting unnecessary electronic documents. I only kept the useful stuff. My email inbox was always empty, because everything got promptly moved to a folder.
Everybody's desk was really clean, and we had no file drawers. We did all have at least two monitors.
Distribute documents electronically (e.g. Sharepoint) and charge people to print something out. Make sure people have nice, big screens so they can easily read text on screen and LCDs so the refresh rate doesn't hurt their eyes.
Get rid of the printers.
Seriously.
I realize that's not realistic. I've tried to help my wife's store go paperless and that's just 4 employees but because the printer is still there they just won't do it. It helped that I set the default printer on all the workstations to print to a Windows share using a PDF writer print driver so some of the problem is solved (we have a few boxes of daily sales reports in her office which fortunately are no longer generated).
My company brings laptops to our Monday status meetings and then has printed copies of the agenda circulated (which we all have a copy of in email). You just can't win really.
As others have mentioned, you may not win, but if your general inclination is to go green, tips and tricks can be found at my friend's blog:
Green User Group
Don't.
I find having a manual or programming reference a lot more useful when I can have it laying open on my desk next to me rather than tabbing back and forth between that and Eclipse and all the other stuff I have open at once. Besides, I like being able to stuff post-its all over the place, underline important passages, etc. Losing the ability to grep the document really isn't an issue. If it's a reference that I know well, I won't have any problem finding the passage I need, and then it will be handily on my desk where I just glance over rather than moving windows around on the screen.
If, for some reason, this is something you REALLY need to do, get rid of the printers and give your developers two or three large LCDs each. I think a better alternative is to set the printers to do automatic duplexing, and provide a comb binder in the copy room. That will encourage people to treat the printouts as "books", rather than a stack of paper that ends up getting thrown out at some point. Rather than throwing the packet out when they are done, it goes on their bookshelf and they pull it out again when they realize they still need it, rather than printing another copy.
If you're so concerned about being "green", buy recycled paper and have more recycle bins than trash cans. Make it easier to recycle than to throw away.
Go buy yourself a really good document scanner. You will always have some amount of incoming paper, if you can easily convert those to digital it will help greatly. I'd recommend a Fujitsu ScanSnap 510.
And make sure you have really good damn backups :)
This all depends on personal preference. Some people like to read on computer screen. But some people might do not prefer screen. They tend to take the print out of every possible thing.
IMO you can promote the use of duplex printing. Infact printing multiple pages on same A4 sheet. This should reduce the wastage to some limit.
Otherwise I know a company which publishes the weekly list of people who got maximum print outs on working areas. This will certainly discourage some people who just take a print out for the sake of taking print out.
Just because you prefer not to use paper doesn't mean that everyone else can work effectively that way. Some of us find the screen hard to read at times. My boyfriend who recently died couldn't read a resolution smaller than 800X600. That means you can't really see much at one time on the screen.
Personally if I am trying to find something like where a missing end should go in a long stored proc, I find that I can see it much faster by printing the whole thing out and looking at it that way. Plus I find it handier to take notes on a piece of paper than an electronic document.
Also, I read extremely quickly, I can read a document probably 3-4 times faster on paper than on screen (in part becasue I don't have to stop to scroll). Yeah I have a big enough monitor to see a whole page at a time, but with my bifocals, I can't actually read it when the type is that small. Why should I waste my time reading on screen when paper is faster for large documents? And if I need to reference back and forth between pages while reading, it is much faster to flip to a page than to search for it electronically.
And remember not everyone has large monitors or the dual monitors that many developers have. They therefore can't see much on the screen at one time and can't see two pages of a document pulled up simulataneously when they need to refer back and forth while reading.
So basically what I'm saying is that paperless offices are less efficient for many people which is why they aren't really popular.
Fire.
(sorry couldn't resist)
Getting rid of printer adn copiers would force everyone to go paperless, but I don't think it is a ideal solution. I would recommend setting up a good recycling program instead. Paper is easily recycled. Also most paper today comes from managed forests. The impact on the environment is minimal. Also get some good scanners, OCR software, and set up servers with plenty of storage to work as virtual filing cabinets.
I like paper, and I think it's the best surface for reading. In my opinion, you shouldn't ban printing - or force the office to go paperless.
Instead, maybe you could encourage reuse. Once a document has been printed and read - distribute it to colleagues who might also need it. The 'round-robin envelope' (for want of a better name) is a feature of many traditional office environments which is pretty good in this respect.
Also print double sided.
First of all, everybody needs to be using LCD, as it is easier to read off of.
Second, tell everybody they can get a second LCD, only if they promise to not print stuff they can read on their LCD.
Also give a short lesson on how to use two monitors effectively. (Mostly, one for main work, second for reading)
He is good programmer (won some competitions) but he absolutely ignores formatting.
He consider i, j, k beautiful... I hope he won't find out about existence of goto keyword.
Write some code in his "style" and then ask him to read it and explain to you what it is doing.
What's good for the goose and all...
I told my students (post-secondary) that they had the choice of writing code well or of me writing their assignments in the same sort of way that they wrote their code. I told them I would write the following program:
take the text of the assignment
lookup a number of the words in a thesaurus and replace them with obscure versions
remove all punctuation
remove all whitespace
convert everything to lower case
insert random whitespace
capitalize random letters
They could then have the assignment... hey its "right" (all of the words are there) good luck understanding what the assignment is though.
Oddly the complaints stopped at that point :-)
I also compared it to English. We use paragraph breaks, capitalizations, etc... as a convention. When someone chooses not to follow the conventions it makes reading much harder.
tell him about python :)
Make him maintain somebody else's code that's written the way he writes. Then make him maintain somebody else's code that was written with good style.
A combination of FORTRAN77 and Python should sort him out.
Code maintainability
Stuff I didn't care in high school neither :)
Write a bunch of "his" code and ask him to find a particular piece of code.
Give him some badly written code with a bug in it and ask him to find the bug.
Well, if he plans to do this for a living just explain that he will have a very rough life on a real team if he doesn't at least make some effort to follow the team standards. If he doesn't plan to do it for a living, don't worry about it.
You also might determine if there is anyone(s) that he admires. If there is then there is a pretty good chance that they follow standards.
I would point out that having clean code is a sign of a organized and intelligent mind. However, the real killer will be when he writes a large amount of code. I doubt you will be able to convince him because more than likely he is getting excited about the logic of the app and not the process. It will take experience to teach him a harsh lesson. So here are my suggestions.
Give him a project full of messy unformatted poorly named code and let him suffer.
Encourage him to work on a project with a large code base and let him see how well he remembers his own variable names after the 1,000th source file.
You probably can't.
Some people just don't get it.
I use self-describing variable names both at work and in private where noone tells me to. I also got some appreciation at work for using long and understandable names.
If a guy does not do it neither for himself or for your project then you've got that kind of guy. Show him some docs on the source code style policy. Explain why this is important.
You begin to use the right naming convention after you've got some experience and you see how and why this was useful. Without experience it's just an abstract talk.
P.S. Sometimes I get stuck with variable names because I'm not sure if this particular name does conform to the common linguistic style I use in the current project or how would the name scale on the high litterature language. The problem of using bool b1 vs. bool IsSomePropertyAvailable has never come up since the first university years.
I'm pretty sure you can misconfigure a code beautifier to present such horrible output. Obfuscaters are common, and do essentially the same thing (short useless variable names, no indenting, poor use of whitespace).
Give him the assignment of taking an existing program with his style and adding a trivial feature.
Also, take code he wrote 6 months or more ago and give the same assignment.
-Adam
Maybe he's not ignorant, maybe he's just inspired by Kernighan & Pike.
i,j,k is fine for loops.
I personally prefer using 1 letter vars in iterations...
foreach ($test as $t)
{
}
beautiful :D