There are a few things that you really have to consider when you're setting up your site links – the naming convention, cost relative to the underlying WAN transport, frequency of replication, and schedule (that is when replication can even occur).
Naming your site links is something you've got to think about what they're all going to look like in order to do properly. If you deal strictly with point to point links your options should be quite limited in how to name them. I generally go Hub - Spoke for the name, where Hub is either the hub site or the site which is logically closest to the hub (e.g. if you have three sites linked linearly Chicago à San Francisco à Tokyo, I would call the link from San Francisco to Tokyo San Francisco – Tokyo). The second part of this convention is to reverse the name in the description, so if the name is Hub – Spoke, then make the description Spoke – Hub. The reasoning here is simple – assuming you're using a GUI tool to view all your site links in a list, you can sort by the name column to see everything by origin, and the description column by destination. If you've got site links with multiple sites in them, you'll have to think of something smart which makes it descriptive yet manageable – everyone's situation is different here.
Cost is perhaps the most scientific of the three things I mentioned, and it can also be totally irrelevant. The cost of the link is used when computing the spanning tree where you have multiple paths to a site. If you have a series of spokes off a hub that have a single link back to the hub, the cost is actually totally irrelevant in the end. On the other hand if you have multiple paths from one site to another, the cost is how the KCC will create the server connections and replicate data. There are a couple schools of thought when it comes to assigning costs to site links. The first is simply a matter of a formula which relates the speed of the underlying transport to a numerical value which can be plugged into AD. The second is to assign constant proportional cost values to different types or classes of links. I generally go with the first option of linking the cost to the underlying transport, and that's what I'm going to discuss here going forward. Assigning costs to your site links based on the underlying transport between the connected sites requires that you work closely with your WAN group to get all of the circuit information and make sure you're in the loop when they change a circuit so that you can update your information as well. There are a couple of formulas that work well as far as how to cost the links. The key is making sure that you can handle differentiating even high speed links e.g. gigabit vs ten gigabit Ethernet. The formulas I use top out at 38.4 gigabits per second (OC768 speed) at a cost of 1. If you're running links faster than this then you'll need to adjust the math accordingly. The difference in the formulas is that the second which takes the square root of everything makes the numbers a lot more manageable in terms of size, and also the Active Directory Sites and Services GUI has a limitation in that it only supports graphical input of integers up to 16 bits (65535) in size. The actual attribute is a 32 bit integer, so if you're using a script or third party tool to manage site links this may not be a concern.
These are the three formulas that I use, option C being my preferred method as it's much more manageable from a numbers standpoint and the fastest link in your table is always a cost of 1. Option A is the same as option C, just that the numbers are relatively huge and can't be managed through the GUI. Finally, option B is the method Microsoft recommends in the Branch Office Deployment Guide. I divide the link bandwidth by 1024 in order to convert the link bandwidth units to kilobits. The reference bandwidth is your maximum bandwidth which will have a cost of 1, and the link bandwidth is the speed of the underlying transport. You need to use the same units for both in order for this to work – in order to support very slow links and to save any unit conversion confusion, I usually just go with bits:
I've attached a spreadsheet (linked at the end of this post) I created which has most of the common WAN link speeds as well as their costs given all three of the above methods. I added a common name column which is a description that goes with the link speed that is what I normally hear associated with them. From a super technical perspective a couple of the names are not entirely accurate, but this is geared towards systems people not telecom. Feel free to use and customize this spreadsheet to your liking. If you add something cool to it, I'd love to hear about it. All I ask is that you give me credit if you redistribute it.
Now, the other piece of the pie when it comes to the costing is that sometimes you need to fudge things a bit (or a lot) in order to make your topology ideal. Let's take a couple examples of this. The first is that you might have a lower cost path which is actually significantly saturated most of the day. The alternative while slower is not highly utilized and thus is preferable from a reliability and load distribution standpoint. In order to make this work you'll have to fudge the cost of the saturated link to be high enough that the other path is elected. The second is that sometimes WAN links have a monetary cost on a bytes transferred basis (or even anytime they're used such as dialup, but this is something I'll talk about in a bit). This is a scenario where you'll be best served talking to your WAN group to understand how you can best accommodate the cost of the link from a financial standpoint be it not using it or limiting the frequency of your use.
Finally, my last point about site link costing is some confusion that sometimes comes up when you have frame relay clouds. I drew the diagram below as an example of something you might get from a WAN group given a request for some drawings of your network. 
Here we have a frame relay cloud with a hub and spoke setup with Chicago being the hub site. Looking at the link speeds, Chicago as a full T3 going to Sprint, and then each of the spoke sites has a much smaller bandwidth allocated going back to Chicago. Additionally, there is a 56K link between Atlanta and New York City as part of this. The technical term for these links is generally PVCs or Permanent Virtual Circuits. My point here is that when costing your links, you wouldn't use the 45Mbps T3 as your cost for each link, but rather the actual allocated bandwidth to each site which is shown at each router – Miami has a 384Kbps link, San Francisco has a 128Kbps link, etc. Your WAN guys might also use the term "CIR" or committed information rate to refer to this.